New install, how should I set my macports.conf

[Ryan Schmidt]

On Jan 23, 2010, at 04:21, Scott Haneda wrote:

> 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

No. build_arch can only contain a single value.

It's very simple: build_arch contains the single architecture for which ports will be built when not building universal. universal_archs contains the multiple architectures for which ports will be built when building universal. Whether a port builds universal depends on whether the port has a universal variant (defined in the portfile or by MacPorts base or a portgroup) and whether you request the universal variant (either on the command line or in your variants.conf or in some cases automatically by the port itself).


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

"Universal" means "built for multiple architectures". As you noticed, most of Apple's binaries are distributed as 3-way universals: 32-bit PowerPC, 32-bit Intel, and 64-bit Intel. 64-bit PowerPC is presumably not included because the only advantage to using 64-bit on PowerPC is the ability to address more than 4GB of RAM, which is not something most programs need at this point, whereas on 64-bit Intel you additionally get the advantage of having twice as many processor registers available which speeds up all code.

In MacPorts, when you request the universal variant, ports build for the multiple architectures specified in the universal_archs line in macports.conf. By default, this line reads "ppc i386" on Mac OS X 10.5 and earlier, and "x86_64 i386" on Mac OS X 10.6 and later. Yes, x86_64 and i386 are both Intel architectures. There is no point to build PowerPC architectures on Snow Leopard since Snow Leopard does not run on PowerPC computers.

The only reason to build for both PowerPC and Intel architectures is so that you can install a port on one computer (say, an Intel Mac) and transfer the compiled software to a different computer (say, a PowerPC Mac). But that's not really a use of MacPorts I want to advocate. Instead, I would ask that you install MacPorts on the second computer and compile the ports again.

In contrast, there is a very good reason to install ports for both 32-bit and 64-bit Intel architectures, even when you're only going to be using the software on a single Intel Mac: because usually you want 64-bit software, because it's faster on Intel, but some software currently still requires 32-bit, like wine. If you install wine, all its dependent libraries need to be 32-bit. By installing those dependent libraries universal for x86_64 and i386, you allow wine and other 32-bit-only software to use the 32-bit parts and everything else to use the faster 64-bit parts.


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

I only meant to say "I build my ports universal for the architectures x86_64 and i386". This means my macports.conf has the default values for Snow Leopard:

universal_archs		x86_64 i386


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

You specify what universal architectures you want in universal_archs, any combination of between two and four of the available architectures: ppc, ppc64, i386, x86_64. Nonsensical combinations like "ppc64 i386" might not work.


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

If the port has a universal variant but does not compile properly when you select it, then "sudo port install +universal" will end with an error and you can either try to fix the port so it does build universal or you can clean and try again without the universal variant.

If the port does not have a universal variant, then requesting the universal variant has no effect; the port will install without it, as you see. This is not special to the universal variant; you can ask any random port for any random variant, and the install will succeed, but of course without that random nonexistent variant.

$ sudo port install zlib +anonexistentvariant +universal +anothernonexistentvariant
--->  Computing dependencies for zlib
--->  Fetching zlib
--->  Verifying checksum(s) for zlib
--->  Extracting zlib
--->  Applying patches to zlib
--->  Configuring zlib
--->  Building zlib
--->  Staging zlib into destroot
--->  Installing zlib @1.2.3_4+universal
--->  Activating zlib @1.2.3_4+universal
--->  Cleaning zlib
$

I can request variants all day long, but if the port doesn't have a variant of that name, there's nothing for MacPorts to do.

$ port variants zlib
zlib has the variants:
(+)universal: Build for multiple architectures
$


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

Ports can define platform variants, or by other means cause things to happen differently on different architectures or OS versions. For example, graphviz enables Quartz support only on Leopard and later:

platform macosx {
    if {${os.major} > 8} {
        configure.args-delete --without-quartz
        configure.args-append --with-quartz
    }
}

If you were to compile this port on Leopard and try to use the resulting software on Tiger, it would fail because the Quartz support in Graphviz requires features introduced in Leopard. Conversely, if you were to compile this port on Tiger and try to use it on Leopard, it would probably work, but would be missing all the nice Quartz features.

Even in the absence of directives in the portfile, the software the port compiles may make different decisions based on different OS versions or architectures.

What you propose -- building on one arch/OS version and using on a different arch/OS version -- might work, especially if the OS version you want to run on is later than the OS version you built on. But it is not a use case I want to advocate or support. I want to advocate and support installing ports on one computer, and running the resulting software on the same computer.


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

And using "use_configure no" is completely appropriate for this port. It just means that the default universal variant is not available, and if you want universal support, you have to do it yourself.