On Fri, Jan 16, 2009 at 12:43 PM, Mike Frysinger <vap...@gentoo.org> wrote:
> On Friday 16 January 2009 15:16:07 Garrett Cooper wrote:
>> The only variables that should be used are:
>>
>> For tools:
>> AR
>> CC
>> RANLIB
>>
>> For compilation definitions:
>> CFLAGS
>> LDFLAGS
>
> and CXXFLAGS ... merging $(CFLAGS) and $(CXXFLAGS) is never right
Ah, you're right! Forgot about that variable ;.).
> we arent getting tools from configure. but that doesnt mean we cant integrate
> support for doing so ... then people could do the nice:
> ./configure --host=some-other-target
> and it would autodiscover CC/AR/CXX/RANLIB/etc...
Yeah. I may not like configure completely, but that's definitely
an indispensable feature that we should employ.
>> Questionable variables:
>> CPPFLAGS (shouldn't need this -- hints at an infrastructure problem)
>
> that depends. if you're referring to -I paths, then i'd agree that people are
> doing something wrong if they need to pass crazy -I paths in order to get
> successful compilation as their toolchain should be configured properly. but
> some people might want to use -D flags and that's valid (think DEBUG or NDEBUG
> or FORTIFY or ...).
Hmmm... didn't thing about that. Excellent point, btw.
>> -bash-3.00$ make -p foo | grep LIB
>
> neat trick, thanks
Yeah, -d and -p are extremely helpful GNU make flags. Warning
though: they dump out a LOT of output (hence the grep ;P..).
> in general, people shouldnt be sticking libraries at the global level into the
> linking step. however, if you want to build/link against a random debugging
> library (like mudflap), then you'll need to inject the -lmudflap. personally
> i think gcc is sucking here by not converting -fmudflap to -lmudflap at the
> linking step via specs, but that is how it's behaved thus far from gcc-4.0
> (the version iirc mudflap first showed up).
Yes, I agree. Unfortunately requesting bugfixes for stuff like
this probably isn't going to happen in gcc with the supported versions
-- but yeah, that sounds like a bug to me ;\... however, that support
should be partially penalized so when people do set that, they
understand that what they're doing is most likely incorrect. Otherwise
we'll get a host of support emails saying `I enabled this feature, and
my build broke', or `my tests compiled, but why don't they work', or
even worse -- `my test compiles and runs, but my results aren't
correct (false pass, false failure)', etc.
mudflap did show up in 4.x too -- I remember the whole snafu with
Gentoo and gcc-4.x with the mudflap use-flag...
Thanks :),
-Garrett
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
