Default +universal variant for configure-based ports

[Kevin Ballard]

I'm still trying to figure out why everybody keeps suggesting to pass  
-g. Even if autoconf does it by default (which I don't think it  
should), that doesn't mean we should. As Daniel Luke demonstrated in  
the "Why -O and -g in universal variants?" thread, debug information  
greatly increases the size of the binary.

The other day, Elias Pipping asked me on IRC why his universal build  
of gettext was half the size of the non-universal build, when it  
should be the other way around. I pointed out that his non-universal  
build used -g.

I'm personally in favor of passing either -O or -Os when building  
universal. I would also consider setting this as the default value  
for CFLAGS to prevent autoconf from using -g by default, but I don't  
know if there are any projects out there that would normally add  
other switches that this would override, to a detrimental effect.

On Feb 26, 2007, at 7:34 AM, Vincent Lefevre wrote:

> On 2007-02-26 07:14:31 -0500, Salvatore Domenick Desiano wrote:
>> I guess it's unclear to me as well why we wouldn't follow TN2137 by
>> default.
>
> This would be a good idea, but other CFLAGS options may be needed
> for some ports, in particular a different optimization option. So,
> it is important that CFLAGS is built in a consistent order.
>
> IMHO, to avoid problems, MacPorts should have a default CFLAGS value,
> e.g. "-O -g" (as suggested by Apple). Then there should be a command
> to append options to CFLAGS before calling configure, e.g.
> configure.cflags-append. The universal variant should have
> configure.cflags-append \
>   "-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"
> and the portfile could add other options if need be. Perhaps ditto
> for LDFLAGS. This way, there shouldn't be any problem with overridden
> CFLAGS/LDFLAGS.

-- 
Kevin Ballard
http://kevin.sb.org
eridius at macports.org
http://www.tildesoft.com


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/macports-dev/attachments/20070227/8f2ff2a7/attachment.html