Re: multiple targets, different build options

[John Richetta]

Peter,

On Sep 24, 2008, at 10:24 AM, Peter Johansson wrote:

> John Richetta wrote:
> > (I'm an autotools newbie.)
> >
> > What is the automake sanctioned way of providing different top- 
> > level make targets, that build my application with different options?
> >
> > For example, say I want to build foo_nondebug, and foo_debug, and  
> > (luckily) all of my application code resides in the subdirectories  
> > of the top level directory containing the top-level Makefile.   
> > Obviously, if I invoke make from one of these targets, I can use  
> > the traditional trick of passing a sub-make arguments (like  
> > FOO_DEBUG=-g or FOO_DEBUG=<empty>).
> I use the following snippet in one my projects:
>
> AC_ARG_ENABLE(debug,
>    [AS_HELP_STRING([--enable-debug],[turn on debug options and  
> code])],
>    [SD_CXXFLAGS="$SD_CXXFLAGS -g -O"],
>    [SD_CPPFLAGS="-DNDEBUG" SD_CXXFLAGS="$SD_CXXFLAGS -O3"])
>
> # Export flags
> AC_SUBST([SVNDIGEST_CPPFLAGS], $SD_CPPFLAGS)
> AC_SUBST([SVNDIGEST_CXXFLAGS], $SD_CXXFLAGS)
>
> and then in each Makefile.am:
>
> AM_CPPFLAGS = $(SVNDIGEST_CPPFLAGS)
> AM_CXXFLAGS = $(SVNDIGEST_CXXFLAGS)

This is definitely better than no solution.  I was aware that  
something like this was possible, but I appreciate seeing the details.

> This will add a switch to configure so we can call ./configure -- 
> enable-debug when we wanna build in debug mode, and else ignore the  
> option. Their is no dependency, so if I switch between the modes in  
> the same builddir I need to issue make clean.

This is certainly workable, but I would prefer to avoid using the  
(lengthy) configure process to change simple things like compile  
options for this application.  If it's not possible, I guess we'll  
have to live with that.  Obviously, side-stepping any issues arising  
from stale .o files is a good thing, to put it mildly.

It would be best if somehow I could ensure that make clean was always  
run after a reconfigure.  I'm guessing I can probably figure out how  
to do that - build in some dependency on config.status's timestamp,  
perhaps?

> Hope this helps.
>
> Cheers,

Thanks for your helpful reply.

-jar