New install, how should I set my macports.conf

Sat Jan 23 02:21:58 PST 2010

On Jan 22, 2010, at 4:59 PM, Ryan Schmidt wrote:

> On Jan 22, 2010, at 18:20, Scott Haneda wrote:
> 
>> For reasons that are too silly to repeat, I am now sitting on a clean 10.6 updated install, with a new MacPorts, and zero ports installed.  I will be installing all my ports new and clean.
>> 
>> In macports.conf I see:
>>   # CPU architecture to compile for. Defaults to i386 or ppc on Mac OS X 10.5
>>   # and earlier, depending on the CPU type detected at runtime. On Mac OS X 10.6
>>   # the default is x86_64 if the CPU supports it, i386 otherwise.
>>   #build_arch                     i386
>> 
>> And also:
>>   # Options for Universal Binaries (+universal variant)
>> 
>>   # machine architectures
>>   universal_archs         x86_64 i386
>> 
>> This is a MacBook that I use for development, 1.83 Intel Core 2 Duo
>> 
>> I am thinking I want to build UB for everything.  This just seems better in the long run.  I will run into the problems of some ports not being able to support it, and can work to solve those problems, or file tickets to get them solved.  Is this a good or bad idea?
> 
> I personally do this (x86_64 i386 universal) since I must in order to build wine. But as you say some ports will not build this way at this time, so watch out and be prepared to retry without universal. (sudo port clean problemport && sudo port install problemport -universal)

I am still not understanding this.  I add multiple values to build_arch and uncomment it?
#build_arch                     i386
 -- would become --
build_arch	x86_64	i386

Arent those both intel specific architectures?  I was under the impression a Universal Binary was a 4 way thing, and would support PPC as well, so some portion, if not all of this list:
386 ppc ppc64 ppc7400 ppc970 x86_64

Or is it just going to be impossible to expect to build for PPC as well on an Intel machine?  I suppose I do not even want to, as it is just bloat? 

I just ran `file` on some of the more popular binaries that Apple ships, and I find all of them are three way, take httpd for example:

$file /usr/sbin/httpd
/usr/sbin/httpd: Mach-O universal binary with 3 architectures
/usr/sbin/httpd (for architecture x86_64):	Mach-O 64-bit executable x86_64
/usr/sbin/httpd (for architecture i386):	Mach-O executable i386
/usr/sbin/httpd (for architecture ppc7400):	Mach-O executable ppc

So ppc and ppc64 are missing.  I am only asking as I am in a position to start clean.  If I make a poor decision now, I will have to go back and rebuild all my ports, which is risky for some.  `mtr` is not something I am worried about, but some of the more complex chain dependent ones where my own personal files become part of the install, I worry about just firing off even a `upgrade` command, let alone something that will run the entire install list and just upgrade them to a new arch.

You mentioned you used "x86_64 i386 universal", I am assuming that is the value you have for "universal_archs"?  Can you explain that some?  As "universal" seems a keyword, not a real architecture of any form.

>> Would I just delete the i386 string from the "universal_archs"?
> 
> No... that would leave your universal_archs with just "x86_64", and a single architecture kind of by definition wouldn't be universal. You would leave universal_archs as it is and build your ports with the +universal variant so they are built for x86_64 and i386.

Got it.  But why then, do those ports that support the +universal at best seem to be building out a 2 way file, at most three? There is an entire line of PPC arch's that I am not seeing mentioned, and not understanding.

>> I add +universal to most oft the ports I installed in the past, which sometimes got me into trouble, as for example, with php5-mcrypt, I had to also rebuild the entire chain that it was dependent on.  
>> 
>> Where do I define that I need not remember to add +universal, and it will be the default, and is that even a good idea?
> 
> variants.conf. I do this, as indicated above.

At the bottom of variants.conf I added:
+universal

I assume that is the same as appending +universal to a `port install` command.  And if something does not work, or I `port info` a port and notice there is no universal variant, I simply -universal and it will over-ride it?

I just ran:
$sudo port -d install memtester
$port installed
The following ports are currently installed:
  memtester @4.1.2_0 (active)

$file /opt/local/bin/memtester
/opt/local/bin/memtester: Mach-O 64-bit executable x86_64

But I had +universal set in variants.conf, I thought this would stop it in it's tracks, and force me to make a decision as to what I need to do at that point.  How would I know this port needs altering for fixing, if it just went in clean?

Or I guess this is unique, and has to do with:
DEBUG: not using configure, so not adding the default universal variant

If this was using configure, then I would have been stopped?

>> Looking for suggestions on the pros and cons.  I am also fine with just leaving things are they are, but it is my understanding that means my builds are only good for this machine or very similar machines.
> 
> I would say MacPorts builds are always only good for this machine or very similar machines. Certainly the major OS version (10.4, 10.5, 10.6) and CPU architecture (ppc, ppc64, i386, x86_64) must match.

How come?  Why could I not built out mcrypt.so for all 4 of those architectures, and have a .so extension I could share with others if I desired?  I am asking this from a technical perspective, not that there is any desire to do such a thing. Though in thought, it may be nice, one could make a fully portable MAMP stack, use Apples Package Maker, or the inbuilt stuff in MacPorts, put the bits where the need to go, and you should have a MAMP system up and running on any machine from a old G3 imac forward.  Or am I reading into this all wrong?

>> I am still at a loss, for example, with my memteter Portfile, which does not have a +universal variant.  What would happen under an install of that port, where I add +univeral?  I assume it will just ignore that and build it for this architecture.
> 
> memtester has no universal variant because it sets "use_configure no". Therefore it will build for build_arch.

I only did so because that is how the README for the source got me thinking:
    memtester is currently only distributed in source-code form. Building
    it, however, is simple -- just type `make`.  There's no `configure` script
    or anything like that.  

But it also states:
    If you have a really strange system/toolchain, you might need to edit the
    conf-cc or conf-ld files, but try to build it without changes first.

I do not really know what to put into those files, or if I should skip that method and use some form of configure appending.  However, since the source does not use configure, I guess I have to go the road of editing the conf-cc and conf-ld files.

I will do what I can to learn more about this stuff, this is really not my area of expertise though.  Any pointers are appreciated.

>> But then I look at `port info mtr` and see it has:
>> Variants:             darwin_10, universal
>> 
>> But looking at the Portfile, these are the only things I see different to me:
>> configure.args-append --without-gtk
>> 
>> platform darwin 10 {
>>   configure.env-append LIBS=-lresolv
>> }
>> 
>> Is that all I have to do, is add in some appended args and will get universal?  I suspect I need to go back to the source, and read through it and see what it takes to build memtester out universal, but I am still at a loss as to what is generating the "Variants: darwin_10, universal" line.
> 
> mtr has a universal variant because it does not contain the lines "use_configure no" or "universal_variant no" and therefore inherits the default universal variant defined in MacPorts base which works for most autoconf-based software.
> 
> mtr has a darwin_10 variant because it contains a section "platform darwin 10".
> 
> To create a universal variant for ports that aren't standard and can't use MacPorts' built-in universal variant, simply define one:
> 
> variant universal {
> 	[do whatever's necessary to build universal]
> }

Ok, so that is the tricky bit I am going to need to figure out with memtester, thanks.

> It may be instructive to grep existing portfiles for "variant universal" to see what they do.

I just did that, there is a lot of stuff in there to go through, thanks for the suggestion. Hopefully I find one with use_configure set to no, and also still showing "variant universal".  I *think* that will get me closest to the changes I need to make in the memtester Portfile.

Thank you again for all your help.
-- 
Scott * If you contact me off list replace talklists@ with scott@ * 