+universal help

[Ryan Schmidt]

On Jan 28, 2010, at 01:31, Scott Haneda wrote:

> On Jan 27, 2010, at 10:51 PM, Ryan Schmidt wrote:
> 
>> Committed.
> 
> Thanks.  When one says "committed" does that mean I can run `port -d sync` and I should see that new port, and any others come in?  I forgot the -d and got blank, so I could not answer that one on my own this time around.
> 
> I suppose there are various rsync servers I may have to wait on to grab it from, but in most cases, "committed" means, sync and you should have it, relatively soon?

If your dports are using rsync (which is the default method of syncing), you'll get the change as soon as the rsync server syncs with the Subversion repository, which happens every half hour.

If your dports are using Subversion, you can get the change immediately after it's committed.


> Can build dependencies be uninstalled with no harm, as they are only needed during build time?

Yes. MacPorts permits you to uninstall build dependencies, but prevents you from uninstalling library and runtime dependencies.


>> Perhaps the reason is that perl5.8 itself could not build universal until ten days ago (see r62847). Perhaps it's now possible to build perl modules universal as well. Someone should test that.
> 
> Is that a possibility for me to test if it is disabled at the source?

You can remove "universal_variant no" from the portgroup and then test if the ports in that portgroup can build universal.


>> It also works fine if you just disable the embedded server, which most people don't need. That's the +no_embedded_server variant. Then you can use the +universal variant. The embedded server is built by default solely for the benefit of amarok. I am inclined to not build the embedded server by default, and change the +no_embedded_server variant into an +embedded_server variant, so that mysql5 can build universal by default.
> 
> I do not know what amarok, but if they made concessions for one feature for one application or service, that seems silly.  I completely agree with you that it should be a +embedded_server variant instead, that makes a heck of a lot more sense.

Well, it started out as a variant in mysql5-devel. Then it became the default in mysql5-devel. As I recall, these changes were made by the maintainer of amarok, not me. Then when mysql5 was updated to 5.1, I copied every change from mysql5-devel, including those. Then when I became aware of how this was preventing universal builds, I added the no_embedded_server variant. But, I would really like to go back to the way it was originally, where the embedded server is not built by default, since most users don't need it and it breaks the universal build.

> However, then that build bug never gets any more attention. :(

If MySQL AB is in the habit of ignoring submitted bugs, then that's true. However, I hope they are not in that habit.


>> Some developers can't tolerate autoconf's bloat, complexity and general not-the-best-way-of-doing-things-ness and either roll their own configure scripts, use a competing product (e.g. cmake), or if their software is simple enough (few files to compile, few dependencies) they can get away with just writing a Makefile and forgoing the configure script entirely. Except that then in MacPorts we have to manually handle CC, CXX, CPP, CFLAGS, CPPFLAGS ,CXXFLAGS, LDFLAGS and other variables, since MacPorts only passes them to the configure script; if there isn't a configure script, then the variables don't get passed anywhere, and if there's a homegrown configure script, it may not respect these variables.
> 
> Really quickly, Xcode just has a "Build" or "Build and Go" button I think.  I have only poked at it a second or two.  Does all this magic happen behind the scenes, or does an xcode style, or I guess I should say, Mac OS X GUI based desktop app, not use the above explained autoconf mechanism?

Correct, Xcode projects are another alternative to configure scripts.


>>> For example, `mtr` needs "configure.env-append LIBS=-lresolv" for 10.6, but apparently does not need it for lesser versioned OS's?
>> 
>> Presumably that's correct. Looking through the log, I added this in r56011 specifically to fix Snow Leopard, as reported on the list:
>> 
>> http://lists.macosforge.org/pipermail/macports-users/2009-August/016147.html
> 
> Is your name not attached to everything I seem to need to get my hands on :)  Any handy tools as a every day developer / small ISP system admin that I am missing out on that I may not know about?

Not sure. :)


>>> Or I must have this wrong, as `port info mtr` lists "darwin_10" as a variant, implying I can apply that to any version OS I desire.  So yeah, still a little muddled in this area.
>> 
>> You should not try to select +darwin_10 on any other platform. In fact, MacPorts will prevent you from doing so:
>> 
>> $ sudo port install mtr +darwin_10
>> Password:
>> Warning: Implicit variants should not be explicitly set or unset. darwin_10 will be ignored.
>> --->  Computing dependencies for mtr
>> --->  Fetching mtr
>> ^C
> 
> Then why is it shown as a variant, that is confusing?
> 
> This makes the most sense, but I rarely use the variants keyword to port.
>    $port variants mtr
>    mtr has the variants:
>       darwin_10: Platform variant, selected automatically
>       universal: Build for multiple architectures
> 
> I usually use the info keyword:
>    $port info mtr
>    mtr @0.75 (net)
>    Variants:             darwin_10, universal
> 
> That would make me, and I suspect most others, believe that `port install mtr +darwin_10` is a viable option.  Would a condition of if current_platform in variant_list then remove_current_platform_variant.  Or you get the idea.

I don't know how to answer you, other than to say that platform variants and regular variants share a lot of code in MacPorts base. They're quite similar in most ways. The differences are that platform variants can have more than one word for their name (i.e. "darwin 10") whereas normal variants can only have a single word; and platform variants are automatically selected by MacPorts. Apologies if it appears from the output of "port info" or "port variants" that you should or can select such variants manually, but that is not the case. At least we have now fixed the problem such that selecting (or deselecting) a platform variant now prints an error message and is ignored; MacPorts used to let you select (or deselect) these manually, which was of course detrimental to the correct functioning of the port.