On Tue, Apr 04, 2006 at 02:20:39PM -0400, Chris Pickett wrote: > Ralf Corsepius wrote: > >However, from my experience, implementing proper and safe checks is > >close to impossible. Not even relying on the fact of using GCC or a > >particular architecture is feasible. In longer terms, any "games" with > >optimization or arch-flags are likely to fail. > > Ok. It would be nice of you to add a note to the relevant FAQ entry in > the Automake manual explaining all of this. presumably, if you are adding stuff, you already know exactly why you are adding it, exactly what it does, and exactly what the consequences are. no different than anything else in computing. > >>Second, how am I actually meant to deal with this situation: > >> > >>1) I want one set of CFLAGS for all builds that specifies a lot of > >>strictness > >>2) I want one set of additional CFLAGS for debugging/profiling builds > >>3) I want one set of additional CFLAGS for optimized/release builds > >>4) I am willing to change the sets by hand depending on compiler+compiler > >>version detected; it will be gcc in most if not all cases; I'm also > >>willing to force compiler upgrades on others. > >>5) I'd like configure to let me choose between debugging and optimization > >>(I'll give this up if there is some other easy way). > > > >The general answer to all these points would be: Let the user run > >multiple configuration runs, one for each configuration. > > > >... > >mkdir debug > >cd debug > >../src/configure CFLAGS=<cflags> CPPFLAGS=<cppflags> > >... > > Yes, but I am also the user, running the package on several different > platforms. Separate aggressively optimized and special > debugging/profiling builds are important: this is a research project > where final numbers do matter because I'm (optimistically hoping I will > be) publishing them. > > I want to make life easy for myself, so to ease both development and > collection of results, using your recommended technique, I would end up > getting the command-line flags from scripts that recognized my current > platform and compiler. Pretty soon this starts to look an awful lot > like what Autoconf provides anyway, and for me, the developer/user, it > still just seems easier inside configure.ac and my Makefile.am's. simpler for you, or someone else? sure, you can make configure do what you want, but then what about when _I_ get your source distribution and try to build it on OpenBSD/sgi? good luck figuring out what my problem is (-O3 is really iffy on that platform) when I come asking you why your software is so buggy. unless of course you can test and debug on OpenBSD/sgi, and anything else someone might want to use your software on. you really think this will be easier for you? you want simple? nothing is simpler than "default". sure, if you are releasing _binaries_, you can build with whatever CFLAGS, since presumably you are also testing the binaries. but for source distributions, it's best to be conservative. > I guess the key assumption I'm making is that the user is willing to > edit the build system, which is currently the case. huh? the user can do ./configre CFLAGS="-O100 -fdo-whatever-on-this-platform" > And, it also seems to me the problem is that, in general, there is no > portable way of specifying compiler flags. huh? it is difficult but not impossible. just don't make assumptions (and yes, adding _anything_ without knowing the full consequences is making assumptions). you need stuff like: # only add -O3 on i386/gcc versions >= 3.0 if USING_GCC if GCC_VERSION_3 if ARCH_I386 AM_CFLAGS="-O3" endif endif endif where USING_GCC, GCC_VERSION_3 and ARCH_I386 are being set in tests in configure. not the greatest example, but hopefully you get the idea. > Shifting the problem onto > the user's shoulders doesn't really do anything for me because they are > the same shoulders! so just do it in your script that runs configure. trust me, adding optimization flags is going to annoy people who are trying to build your software on a platform you don't know about ... and you are going to have a really hard time trying to help them, since you do not know that platform! see, adding these flags makes your job harder! of course, if you are not planning on distributin the software, and really only _you_ will be the user ... but then why would you be using autotools in that case? > > >>And I thought I was being *good* by not clobbering the environment CFLAGS! > > > >That's true. Permanently clobbering the environment with CFLAGS, in many > >cases is harmful, but temporarily doing so, when invoking a command from > >the shell (CFLAGS=<...> configure) or passing CFLAGS as argument to > >configure (configure CFLAGS=<...>) doesn't clobber your environment. > > > >All this does is to cause the configure script to pick up your CFLAGS > >and to propagate it into the files it generates (Makefiles). > > There was a confusion here. I meant to say "command-line CFLAGS" > instead of "environment CFLAGS". The Automake manual specifically says > not to clobber whatever the command-line CFLAGS are, to let the user > have the last say, and I was trying to do that by using AM_CFLAGS and > friends. _but_, AM_CFLAGS will _always_ be added to the compile command. if you have AM_CFLAGS="-O3 -fomit-frame-pointer", the user _cannot_ remove those without editing the build system. you must check that AM_CFLAGS is not going to cause problems on any platform your software will be used on. -- <jakemsr@xxxxxxxxxxx> _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
