Default +universal variant for configure-based ports

[Blair Zajac]

Being somebody who actually digs into stack traces and core dumps, I 
would be extremely leery about loosing the -g flag.  When something goes 
wrong, having the additional debugging information available is nice.

I think there's precedence for keeping it.  Most of the Linux 
distributions I believe build it in by default.  For example, here's a 
build log for Subversion on Ubuntu Dapper Drake:

http://www-devel.orcaware.com/packages/ubuntu/dapper/subversion/log-build-subversion-1.3.2-3zajac1.txt

Lots of -g's in there.

Disk is pretty cheap these days, so I say keep it in.

Regards,
Blair

Kevin Ballard wrote:
> 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.