+universal help

Wed Jan 27 23:31:00 PST 2010

On Jan 27, 2010, at 10:51 PM, Ryan Schmidt wrote:

> On Jan 28, 2010, at 00:28, Scott Haneda wrote:
> 
>> Trac of patch file has been posted: 
>> http://trac.macports.org/ticket/23453
> 
> 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?

>> This actually clears up the last bits of confusion I had with my thread the other day on configuring and setting up macports.conf on a new install.
>> 
>> And I am quite please to be able to show:
>>   $port installed | wc -l
>>         45
>> 
>> So 44 ports installed (line one does not count) on this new system install.
>> 
>> I am a little confused about:
>> 
>>   $port installed | grep -v 'universal'
>>   The following ports are currently installed:
>>     autoconf @2.65_1 (active)
>>     autoconf213 @2.13_1 (active)
>>     curl-ca-bundle @7.19.7_1 (active)
>>     mysql5 @5.1.42_0 (active)
>>     mysql5-server @5.1.42_0 (active)
>>     p5-locale-gettext @1.05_2 (active)
>>     perl5 @5.8.9_0 (active)
>> 
>> I never explicitly installed any of those, (sans Mysql) so they came along with Apache2, or php5, or some other software.  Am I just getting lucky that the universal builds are working with these?  Or is it that as long as those are all the *same* arch, I am fine?
> 
> Build dependencies don't need to be universal, generally. Library and runtime dependencies do.
> 
> autoconf (and the older version autoconf213 which is needed by php5) are build dependencies only so it doesn't matter if they're universal.

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

> curl-ca-bundle does not install compiled software; it only installs a text file. Therefore it has no universal variant.
> 
> Same with mysql5-server, which installs only directories and plists.

Understood on that one.

> p5-locale-gettext is a perl module, using the perl5 portgroup. The perl5 portgroup specifies "universal_variant no"; presumably there is some problem endemic to perl modules preventing them from building universal, so it's turned off for all of them at the source.

Got it.

> 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?

> Note that perl5 is a stub port, doing nothing more than depending on perl5.8 or perl5.10 where the actual software is installed. Since perl5 installs no files, it has no universal variant.

Noted, thanks.

>>   $file `which mysql5`
>>     /opt/local/bin/mysql5: Mach-O 64-bit executable x86_64
>> 
>> Is this the relevant reason for MySql not being able to have a universal variant:
>> http://bugs.mysql.com/bug.php?id=47360
>> 
>> I also found this ticket:
>> http://trac.macports.org/changeset/62287
>> 
>> Since it does not appear there is going to be a timely fix on MySql's part for this, at least, in reading over the bugs.mysql.com thread, would taking the suggestion to use lipo and stuff them together be an option, or does lipo add more build time than is desired, that being the only downside I can estimate.
>> 
>> Just curious, as it does not effect me at this time.
> 
> We could try the muniversal portgroup for the mysql5 port. However I would prefer the developers of MySQL fix this properly upstream.

Me too.

> 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.

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

>>> memtester also doesn't support selecting a different build_arch in macports.conf (portfile variable: ${configure.build_arch}). This is to be expected, since that also happens in a way that assumes a configure-based script; ports that don't use the default universal variant don't by default get build_arch support either. The solution is similar, and the pre-made architecture flag is in the variable ${configure.cc_archflags}.
>> 
>> In regards to the lack of a configure script, why would a developer chose omit it?  How exactly are configure scripts made?  I am assuming that they are not hand coded, but perhaps tuned by hand at some point?  Looking over a few, they look more machine written than hand written.  That being the case, I fail to see why one wold chose to not have a configure step.
> 
> Most configure scripts are machine-generated by a program called autoconf. The developer writes an automake file called configure.am, which gets turned into configure.in, which gets turned into configure, which is what the user runs. autoconf is a very complex program by now with tons of cruft in it; you've seen how large and unwieldy the configure scripts it generates get.

Indeed, which is why I assumed, no mere mortal was writing those :)

> 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?

>>>> My guess would be to add:
>>>> platform darwin 10 {
>>>> # Reinplace foo to alter the above two files
>>>> }
>>> 
>>> This has nothing to do with Snow Leopard specifically so there's no call for a platform darwin 10 section.
>> 
>> Yeah I was sort of stumbling along at this point, using `mtr` and a grep for 'configure no' through all the ports.  I still do not entirely understand the platform "phase"?
> 
> It's not a phase; it's basically a variant that MacPorts auto-selects for you based on the current OS.

Ok.

>> but am gathering, it is how you do specific things for specific platforms.  So darwin 10 == 10.6 and darwin 9 == 10.5 etc etc.
> 
> Yes.
> 
>> If there is ever call for special scenarios just for that OS release, this is where you would do it?
> 
> Yes.
> 
>> 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?

>> 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.

Thank you again Ryan.
-- 
Scott * If you contact me off list replace talklists@ with scott@ * 