Specifying AM_CPPFLAGS from within configure.ac

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Specifying AM_CPPFLAGS from within configure.ac

Matthew Walker-2
Hi,

I would like to know how I should go about specifying AM_CPPFLAGS from
within my configure.ac.

I read Norman Gray and Alexandre Duret-Lutz's discussion from this
mailing list on this topic
(http://www.mail-archive.com/automake@.../msg10024.html) but could
not understand quite what I was supposed to do.

The library that I'm working on has an "--enable--full-debug" mode, and
I would like to ensure that the compiler spits out all the warnings it
can by specifing CPPFLAGS=-Wall.  I have, however, read that setting
CPPFLAGS is a bad thing to do because users should be able to alter that
variable to their hearts content.

I understand that I should instead specify the automake variable
AM_CPPFLAGS.  Now from what I could understand from the Norman and
Alex's discussion, it is possible to do this in configure.ac rather than
having to change every single one of the (many) makefiles.  It has
something to do with AC_SUBST, but that's where I become lost.

Any help will be very much appreciated.  I am _very_ much a newbie to
autoconf/automake and I apologize sincerely if this is a stupid question.

Thank you for your thoughts,

Matthew Walker


Reply | Threaded
Open this post in threaded view
|

Re: Specifying AM_CPPFLAGS from within configure.ac

Jirka Hanika
On Thu, Jun 02, 2005 at 05:50:14PM +1200, Matthew Walker wrote:
> Hi,
>
> I would like to know how I should go about specifying AM_CPPFLAGS from
> within my configure.ac.

For such things, it is VERY useful to add something like this:

include $(top_srcdir)/Makefile.common

at the top of every Makefile.am.  This basically gives you a whole new
dimension of performing package administration.  I'm almost surprised
this feature is not built into the automake to dismiss the (small) initial
work investment.  Now write your own Makefile.common and put everything
into it as you please.

Other people use a single Makefile.am.  That's not bad, either.  Gives
you much faster builds, at some expense of maintainability.

> I read Norman Gray and Alexandre Duret-Lutz's discussion from this
> mailing list on this topic
> (http://www.mail-archive.com/automake@.../msg10024.html) but could
> not understand quite what I was supposed to do.

Put this into your configure.ac:

AC_SUBST(AM_CPPFLAGS)

(or rather, AC_SUBST(AM_CFLAGS) as it is something of a conincidence that the
preprocessor and compilation flags tend to have the same effects.)

> The library that I'm working on has an "--enable--full-debug" mode, and
> I would like to ensure that the compiler spits out all the warnings it
> can by specifing CPPFLAGS=-Wall.  I have, however, read that setting
> CPPFLAGS is a bad thing to do because users should be able to alter that
> variable to their hearts content.

Not every compiler understands -Wall, but newcomers are rarely interested
in hearing that :-)

You are right that CPPFLAGS is not the right tool.

You may wish to stop reading here, and resume reading when you get
automake/autoconf run according to your present wishes :-)
as the rest is less straightforward.

> Any help will be very much appreciated.  I am _very_ much a newbie to
> autoconf/automake and I apologize sincerely if this is a stupid question.

No it's a fairly standard question.  But you'll probably learn over time that
often it is significantly better to approach these problems from a different
angle.  For example, you don't need to meddle with the autotools at all
in your example - just specify CFLAGS as every other builder would.  It is
simple and automatizable, unless you do development on a different host each
day.  The benefit?  People with different compilers will not have to
fight the non-portable -Wall which happens to break their
compilation.

Okay, automake gives you the power to distribute (enforce) the options if you
prefer.  But then the portable way to do this is more complex.

Code like the one at the end of the message, when inserted into your
acinclude.m4 (in the top source directory), gives you a MY_CXX_OPTION
autoconf macro to be used like this:

MY_CXX_OPTION(warnings, [warnings], [-Wall -w -enable-warnings-or-whatever])

in configure.ac, AC_SUBST either "warnings" or AM_CXXFLAGS including these
into the Makefile, and enjoy configure actually selecting the best
warning option from the list for you by examining the actual compiler.
Oh, my example seems to be for C++, so just replace every CXX/cxx by C/c.

If you used CPPFLAGS, the options would affect both C and C++ compilation,
thus there actually IS some difference between CPPFLAGS and CFLAGS.

Jirka

------------------------


AC_DEFUN(MY_CXX_OPTION,
[AC_MSG_CHECKING([for $2])
AC_CACHE_VAL(epos_cv_cxx_opt_$1,
[ cat > conftest.cc <<EOF
#include <stdio.h>
int main(int argc, char **argv)
{
argc=argc; argv=argv; return 0;
}
EOF
epos_cv_cxx_opt_$1=""
for opt in $3; do
    if test -z "${epos_cv_cxx_opt_$1}"; then
        if ${CXX} ${opt} -o conftest conftest.cc 2>conftest2 1>&5; then
            if test -f conftest2; then
                msg=`cat conftest2`
                if test -z "${msg}"; then
                  epos_cv_cxx_opt_$1=${opt}
                fi
            else
                epos_cv_cxx_opt_$1=${opt}
            fi
        fi
    fi
done
if test -z "${epos_cv_cxx_opt_$1}"; then
        epos_cv_cxx_opt_$1="unknown"
fi
rm -f conftest conftest2])
if test "${epos_cv_cxx_opt_$1}" = "unknown"; then
        AC_MSG_RESULT("unknown")
        $1=""
else
        AC_MSG_RESULT(${epos_cv_cxx_opt_$1})
        $1=${epos_cv_cxx_opt_$1}
fi])



Jirka



Reply | Threaded
Open this post in threaded view
|

Re: Specifying AM_CPPFLAGS from within configure.ac

Stepan Kasal
Hello Jirko,

some nit picking:

Regarding your macro MY_CXX_OPTION, if you want to be really portable,
things can get even more scary.  See
http://lists.gnu.org/archive/html/autoconf/2005-05/msg00109.html
This will point you to latest sources in the 1.5.x branch of libtool.
(The thread continues at
http://lists.gnu.org/archive/html/autoconf/2005-06/msg00001.html )


On Thu, Jun 02, 2005 at 10:40:03PM +0200, Jirka Hanika wrote:
> MY_CXX_OPTION(warnings, [warnings], [-Wall -w -enable-warnings-or-whatever])

MY_CXX_OPTION([warnings], [warnings], ...)

all arguments have to be quoted.  It's good rule to keep, at least when we
educate beginners on this list.  ;-)

I think the definition of your macro can be improved.
Here is the new version:

AC_DEFUN([MY_CXX_OPTION],
[AC_CACHE_CHECK([for $2], [epos_cv_cxx_opt_$1],
[cat > conftest.cc <<EOF
#include <stdio.h>
int main(int argc, char **argv)
{
argc=argc; argv=argv; return 0;
}
EOF
epos_cv_cxx_opt_$1=unknown
for opt in $3; do
    ${CXX} ${opt} -o conftest conftest.cc 2>conftest2 1>&5 || continue
    msg=`cat conftest2`
    if test -z "$msg"; then
        epos_cv_cxx_opt_$1=$opt
        break
    fi
done
rm -f conftest conftest2 conftest.cc])
if test "x${epos_cv_cxx_opt_$1}" = xunknown; then
        $1=
else
        $1=$epos_cv_cxx_opt_$1
fi])

Some of the changes are only my taste, but some are important:

AC_DEFUN([MY_CXX_OPTION],
  -- quote the symbol, in case the definition is read twice.

cmd 2>conftest2   always creates conftest2

You forgot to rm conftest.cc.

test "x$epos_cv_cxx_opt_$1" = xunknown
You have to prepend the "x", for portability, see the Autoconf manual.

Have a nice day,
        Stepan Kasal


Reply | Threaded
Open this post in threaded view
|

Re: Specifying AM_CPPFLAGS from within configure.ac

Ralf Wildenhues
Hi Jirko, Stepan,

* Stepan Kasal wrote on Fri, Jun 03, 2005 at 08:44:48AM CEST:
>
> Regarding your macro MY_CXX_OPTION, if you want to be really portable,
> things can get even more scary.

This thread[1] contains a couple more hints.  :)

> I think the definition of your macro can be improved.
> Here is the new version:
>
> AC_DEFUN([MY_CXX_OPTION],
> [AC_CACHE_CHECK([for $2], [epos_cv_cxx_opt_$1],
> [cat > conftest.cc <<EOF
> #include <stdio.h>
> int main(int argc, char **argv)
> {
> argc=argc; argv=argv; return 0;
> }

If what you want is to avoid warnings, then Libtool experience tells:
It's impossible.  There will always be a compiler which warns about your
code.  Your assignments, for example, won't keep some compilers from
recognizing that the values of `argc' and `argv' are never used.

Some (esp. commercial) compilers have the habit of outputting a boiler
plate each time they are called.  With some there even is no option to
turn this off!  Also please note that generally, you cannot try
compilation when omitting the user-specified CXXFLAGS and CPPFLAGS..

> EOF
> epos_cv_cxx_opt_$1=unknown
> for opt in $3; do
>     ${CXX} ${opt} -o conftest conftest.cc 2>conftest2 1>&5 || continue

as you do here.  For example, on some Solaris system, omitting -xarch=v9
(which the user will have put in CXXFLAGS) will produce warnings and may
cause compilation to fail even.  Surely one could argue such flags
belong in $CXX proper, but that's not the nicest treatment of users.

Also, the options may depend on each other (and on options given in
CXXFLAGS/CPPFLAGS), so you should document your macro to not use the
ones given in $1 in sequence.

>     msg=`cat conftest2`
>     if test -z "$msg"; then
>         epos_cv_cxx_opt_$1=$opt
> break
>     fi
> done
> rm -f conftest conftest2 conftest.cc])
> if test "x${epos_cv_cxx_opt_$1}" = xunknown; then
>         $1=
> else
>         $1=$epos_cv_cxx_opt_$1
> fi])

Regards,
Ralf

[1] http://lists.gnu.org/archive/html/libtool-patches/2005-04/msg00080.html


Reply | Threaded
Open this post in threaded view
|

Re: Specifying AM_CPPFLAGS from within configure.ac

Matthew Walker-2
In reply to this post by Jirka Hanika
Hi Jirka,

Firstly, thank you very very much for your comments.  They were well and
truly more thorough than I'd ever hoped for.

Unfortunately, I don't understand much of what you have said.

Jirka Hanika wrote:

>On Thu, Jun 02, 2005 at 05:50:14PM +1200, Matthew Walker wrote:
>  
>
>>Hi,
>>
>>I would like to know how I should go about specifying AM_CPPFLAGS from
>>within my configure.ac.
>>    
>>
>
>For such things, it is VERY useful to add something like this:
>
>include $(top_srcdir)/Makefile.common
>
>at the top of every Makefile.am.  This basically gives you a whole new
>dimension of performing package administration.  I'm almost surprised
>this feature is not built into the automake to dismiss the (small) initial
>work investment.  Now write your own Makefile.common and put everything
>into it as you please.
>
>  
>
I understand this suggestion (!) but I did a quick search and found
there were 81 Makefiles.  If I were to add that text to the top of every
makefile, can you confirm that Makefile.common would have only the line:
AM_CPPFLAGS=-Wall -ggdb

 From your comments below, I understand that this is not entirely
portable and that there is no "easy" solution to this portability
problem.  Also, AM_CPPFLAGS covers both C and C++ while AM_CFLAGS covers
only C.  As the library is in C++, I gather AM_CPPFLAGS is the better
choice.

>Other people use a single Makefile.am.  That's not bad, either.  Gives
>you much faster builds, at some expense of maintainability.
>
>  
>
As the library is not my own, I do not think this option is available to me.

>>I read Norman Gray and Alexandre Duret-Lutz's discussion from this
>>mailing list on this topic
>>(http://www.mail-archive.com/automake@.../msg10024.html) but could
>>not understand quite what I was supposed to do.
>>    
>>
>
>Put this into your configure.ac:
>
>AC_SUBST(AM_CPPFLAGS)
>
>(or rather, AC_SUBST(AM_CFLAGS) as it is something of a conincidence that the
>preprocessor and compilation flags tend to have the same effects.)
>
>  
>
I just do not get this at all.  Where do I *set* AM_CPPFLAGS?  I tried
to understand the documentation for AC_SUBST (section 7.2 of the
Autoconf manual), but for the life of me, I just don't get it.

AC_SUBST subsitutes something for something else.  My imagination tells
me that it probably looks through all the Makefile.am's for the
something, but really I've got no idea.

Here is the part of configure.ac that I thought I could alter:

dnl Open BEAGLE optimization mode option.
AC_ARG_ENABLE(optimization,
  [  --enable-optimization    enable optimization mode [default=no]],
  [case $enableval in
  yes) enable_optimization=yes;;
  no) enable_optimization=no;;
  *) enable_optimization=no;; esac],
  enable_optimization=no)
if test "$enable_optimization" = yes; then
  AC_DEFINE(NDEBUG,,[define if some debug code is disabled])
  CFLAGS=`echo $CFLAGS | sed 's/\(?*\)-g\(?*\)/\1\2/'`         <---- This is already in the file. I don't know what it does
  CXXFLAGS=`echo $CXXFLAGS | sed 's/\(?*\)-g\(?*\)/\1\2/'`           but my guess is that it would be better if it didn't set
else                                                                 CFLAGS or CXXFLAGS.
  CFLAGS=`echo $CFLAGS | sed 's/\(?*\)-O[[0-9]]\(?*\)/\1\2/'`  <----/
  CXXFLAGS=`echo $CXXFLAGS | sed 's/\(?*\)-O[[0-9]]\(?*\)/\1\2/'`
fi

dnl Open BEAGLE full debug mode option.
AC_ARG_ENABLE(full-debug,
  [  --enable-full-debug      enable full debug mode [default=no]],
  [case $enableval in
  yes) enable_full_debug=yes;;
  no) enable_full_debug=no;;
  *) enable_full_debug=no;; esac],
  enable_full_debug=no)
if test "$enable_full_debug" = yes; then
  AC_DEFINE(FULL_DEBUG,,[define if full debug mode is active])
  CPPFLAGS=-Wall                                               <---- This is my effort. It works but shouldn't set CPPFLAGS either.
fi


Can you show me how I would use AC_SUBST to replace my "CPPFLAGS=-Wall"?

>>The library that I'm working on has an "--enable--full-debug" mode, and
>>I would like to ensure that the compiler spits out all the warnings it
>>can by specifing CPPFLAGS=-Wall.  I have, however, read that setting
>>CPPFLAGS is a bad thing to do because users should be able to alter that
>>variable to their hearts content.
>>    
>>
>
>Not every compiler understands -Wall, but newcomers are rarely interested
>in hearing that :-)
>
>You are right that CPPFLAGS is not the right tool.
>
>You may wish to stop reading here, and resume reading when you get
>automake/autoconf run according to your present wishes :-)
>as the rest is less straightforward.
>
>  
>
>>Any help will be very much appreciated.  I am _very_ much a newbie to
>>autoconf/automake and I apologize sincerely if this is a stupid question.
>>    
>>
>
>No it's a fairly standard question.  But you'll probably learn over time that
>often it is significantly better to approach these problems from a different
>angle.  For example, you don't need to meddle with the autotools at all
>in your example - just specify CFLAGS as every other builder would.  It is
>simple and automatizable, unless you do development on a different host each
>day.  The benefit?  People with different compilers will not have to
>fight the non-portable -Wall which happens to break their
>compilation.
>  
>
I found this the most interesting/easy idea.  All I need to type is:
make 'CPPFLAGS=-Wall -ggdb'
or better yet:
./configure --enable-full-debug 'CPPFLAGS=-Wall -ggdb'
and everything seems to be lovely.  This is great for me, but I still
think it might be beneficial, for debug mode, to somehow set all
warnings to be on.  As I understand it, the code you provided checks for
the best warning settings for a user's compiler.  (I feel this is cheeky
of me seeing I'm just starting, but...)  Why isn't such code already
part of autoconf?


Thank you again for your fantastic assistance.

Regards,

Matthew


Reply | Threaded
Open this post in threaded view
|

Re: Specifying AM_CPPFLAGS from within configure.ac

Jirka Hanika
Hi Matthew, Stepan, Ralf,

first let me thank Ralf and Stepan, for your comments about the code
snippet, I've learned a lot.  You are both right.

For example I'll try to upgrade the "unused variable" warning avoidance
code to something like

if (((int)argv) * ((int)argv) < 0 || argc < 0) printf("");

and accept the fact that bannered compilers will simply select no option.
Hope the libtool experience doesn't suggest that the newest gcc will see
through the trick, too.


Now at least briefly:

> I understand this suggestion (!) but I did a quick search and found
> there were 81 Makefiles.  If I were to add that text to the top of every
> makefile, can you confirm that Makefile.common would have only the line:
> AM_CPPFLAGS=-Wall -ggdb

Yes.  One line.  In my projects it simply turned out that Makefile.common
changes more often than all Makefile.am's taken together.  It may or may
not in your case, too.

Besides, you can probably do that change automatically, using
find and sed, so 81 is not that bad.  A few minutes.

> From your comments below, I understand that this is not entirely
> portable and that there is no "easy" solution to this portability
> problem.  

Except for specifying the flags "from outside" (not manually) at
configure time, yes.

> Also, AM_CPPFLAGS covers both C and C++ while AM_CFLAGS covers
> only C.  As the library is in C++, I gather AM_CPPFLAGS is the better
> choice.

I'd choose AM_CXXFLAGS in that case.  That's the one for C++.  CPPFLAGS
is for preprocessor only (-D, -I ...), although it will mostly work the
same.

> >Other people use a single Makefile.am.  That's not bad, either.  Gives
> >you much faster builds, at some expense of maintainability.
>
> As the library is not my own, I do not think this option is available to me.

I see.

> I just do not get this at all.  Where do I *set* AM_CPPFLAGS?  I tried
> to understand the documentation for AC_SUBST (section 7.2 of the
> Autoconf manual), but for the life of me, I just don't get it.

You set it in Makefile.am, or in a file included from there.

The AC_SUBST only says that you want this option propagate down to the
Makefile, as a make variable.  The Makefile will use it in any case (empty
or not), because its reference has been generated by automake/configure
as a part of compilation commands.

> AC_SUBST subsitutes something for something else.  My imagination tells
> me that it probably looks through all the Makefile.am's for the
> something, but really I've got no idea.

Almost.  Looks for @AM_CXXFLAGS@ in every Makefile.in and replaces it
with the configure variable of the same name.  But its configure,
not automake, who does this.  Automake only copies the assignment to
Makefile.in.

> Can you show me how I would use AC_SUBST to replace my "CPPFLAGS=-Wall"?

No, it is a good exercise for you, but I'll tell you a simpler
alternative to start with :-)

AC_SUBST also has a two-argument form.  The second argument is the value
you want to assign to the variable.  In a trivial case, like this:

AC_SUBST(AM_CXXFLAGS, [-Wall])

> >No it's a fairly standard question.  But you'll probably learn over time
> >that
> >often it is significantly better to approach these problems from a
> >different
> >angle.  For example, you don't need to meddle with the autotools at all
> >in your example - just specify CFLAGS as every other builder would.  It is
> >simple and automatizable, unless you do development on a different host
> >each
> >day.  The benefit?  People with different compilers will not have to
> >fight the non-portable -Wall which happens to break their
> >compilation.
> >
> >
> I found this the most interesting/easy idea.  All I need to type is:
> make 'CPPFLAGS=-Wall -ggdb'
> or better yet:
> ./configure --enable-full-debug 'CPPFLAGS=-Wall -ggdb'
> and everything seems to be lovely.

Yes, something along these lines.

>   This is great for me, but I still
> think it might be beneficial, for debug mode, to somehow set all
> warnings to be on.

Yes.  May happen.

>  As I understand it, the code you provided checks for
> the best warning settings for a user's compiler.  (I feel this is cheeky
> of me seeing I'm just starting, but...)  Why isn't such code already
> part of autoconf?

As Ralf just taught me, it is probably very hard to get right for every
possible use case.  My needs were pretty modest at the time I needed
this and I snatched the code from somewhere and adapted it without much
scrutiny.  Maybe you can ask at the autoconf list instead of here.

Jirka



Reply | Threaded
Open this post in threaded view
|

Re: Specifying AM_CPPFLAGS from within configure.ac

Andreas Schwab
Jirka Hanika <[hidden email]> writes:

> For example I'll try to upgrade the "unused variable" warning avoidance
> code to something like
>
> if (((int)argv) * ((int)argv) < 0 || argc < 0) printf("");

conftest.c: In function ‘main’:
conftest.c:5: warning: cast from pointer to integer of different size
conftest.c:5: warning: cast from pointer to integer of different size
conftest.c:5: warning: zero-length printf format string

conftest.cc: In function ‘int main(int, char**)’:
conftest.cc:5: error: cast from ‘char**’ to ‘int’ loses precision
conftest.cc:5: error: cast from ‘char**’ to ‘int’ loses precision
conftest.cc:5: warning: zero-length printf format string

Andreas.

--
Andreas Schwab, SuSE Labs, [hidden email]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."


Reply | Threaded
Open this post in threaded view
|

Re: Specifying AM_CPPFLAGS from within configure.ac

Jirka Hanika
On Mon, Jun 06, 2005 at 03:12:48PM +0200, Andreas Schwab wrote:

> Jirka Hanika <[hidden email]> writes:
>
> > For example I'll try to upgrade the "unused variable" warning avoidance
> > code to something like
> >
> > if (((int)argv) * ((int)argv) < 0 || argc < 0) printf("");
>
> conftest.c: In function ‘main’:
> conftest.c:5: warning: cast from pointer to integer of different size
> conftest.c:5: warning: cast from pointer to integer of different size
> conftest.c:5: warning: zero-length printf format string
>
> conftest.cc: In function ‘int main(int, char**)’:
> conftest.cc:5: error: cast from ‘char**’ to ‘int’ loses precision
> conftest.cc:5: error: cast from ‘char**’ to ‘int’ loses precision
> conftest.cc:5: warning: zero-length printf format string

Thanks.  I think I'm finally getting to see the point.

(Now I remember this cast warning already bit me in other code a long
time ago.  I then switched to assigning an unused expression to an extern
variable, which worked for me.  Doesn't change the point.  Absolute
compiler output is a silly thing to check.)

Jirka



Reply | Threaded
Open this post in threaded view
|

Re: Specifying AM_CPPFLAGS from within configure.ac

Ralf Wildenhues
In reply to this post by Ralf Wildenhues
Hi Jirka,

* Jirka Hanika wrote on Sat, Jun 04, 2005 at 10:12:18PM CEST:
>
> I've decided to send one more piece of reaction directly to you, because it
> doesn't belong to the automake list anymore and it might confuse the
> AC_COMPILER_OPTION thread on the autoconf list unless verbosely
> introduced.

Actually, I believe this is very much on-topic on the list, and also of
potential interest to others.  I hope you don't mind I copy to the list
(I also don't like much to discuss public matters in private).

> In fact the reason why I initially meddled with that option selection
> macro was that on Mac OS X, a project of mine required some aboriginal
> -framework whatever linker option (well, maybe a compiler option, I don't
> have direct access to check) to build at all.  So I decided I want to
> feed the option to every compiler which will at least ignore it.

Not a very good idea, I believe.  I know we put a lot of extra stuff for
Darwin into Libtool (but I am very ignorant of it myself, so I am very
much the wrong person to ask).

Somebody _will_ already have encountered the "-framework addition
problem" and might be able to give advice specific to this.  I believe
this should be solved differently from the kind of macro I proposed.

> I can't reasonably expect people to put it in CXXFLAGS or LDFLAGS, as
> the specified framework is project-specific.  On the other hand,
> including such options among CXXFLAGS by the builder is often clearly
> standard practice.  With options which may not be duplicated on the
> command line, this may lead to absurd, though hopefully not harmful effects.
>
> Therefore, unless I'm misusing autoconf, the borderline between CFLAGS and
> AC_COMPILER_OPTION is a fuzzy one.

Well, sometimes you have to have the user specify CFLAGS (my
experience), at least if you want to avoid to ever outsmart her.

> With reference to your planned AC_COMPILER_OPTION I'd like to vote
> for an optional macro parameter specifying the test source.  Most people
> won't need it, for others it will be essential.

Yes, that might be a good idea.

[...]

> >
> > Also, the options may depend on each other (and on options given in
> > CXXFLAGS/CPPFLAGS), so you should document your macro to not use the
> > ones given in $1 in sequence.
>
> (I should perhaps also add that I'm not sure that I fully understand the
> last abovequoted paragraph of yours, nor the argument why you purport to
> run 2*n compilations for n candidate options.  My naive implementation
> would be to run 1 compilation with neither and 1 with every single
> candidate.  Users may group strings of interdependent options using
> shell quoting if that is the desired behavior.  I may be missing something.)

If the user is allowed to specify the source, it will need 2*n
compilations for n different sources.
If the user only specifies one source, we can do with n+1.  We still
need to specify whether to accumulate options or select just one.

As to interdependence of options:  just think of
  -Wall -Wno-unused
with gcc (and an unfortunate source file).  There are much more complex
examples (and the example given is bad as such options should not be put
in there, most likely).

Regards,
Ralf