Re: --with-foo= vs. FOO=${FOO:-foo_default}

[Warren Young]

Troy Cauble wrote:
> I'm porting a large, full-featured, autoconf-based project to an 
> embedded linux
> system where certain features cannot be supported.  The C/C++ files will
> require a -D flag to control some ifdefs.  The Makefile.am's will require
> either ifeq statements or @MY_FLAGS@ style substitutions.
>
> Is the best way to trigger all this with --with, --enable, or something 
> else?

I would first try for "something else".  First factor all the code that 
won't work on your embedded platform out into separate functions, and 
then bundle those up into a libtool convenience library.  Then from 
within the configure script, you can probably find a way to detect 
whether the program is being cross-compiled.  If it is, build and link 
to a dummy version of the convenience library where all of the functions 
 do nothing.

If you can't detect at configure time whether the program is being 
cross-compiled, I suppose just one "--enable-slim-mode" flag (to pick a 
random name) is acceptable, in order to choose whether to link to the 
full-function convenience library or the dummy one.  The effect would 
still be the same: you get to avoid ifdef hell.  That's what autoconf is 
for.

Besides the cleanliness of avoiding ifdef hell, some of the functions in 
the dummy library may be able to fake missing platform features instead 
of simply doing nothing.  For example, if your embedded box won't have a 
network interface but some bit of your code calls gethostbyname() in 
preparation for connecting to a service which is remote on full-size PCs 
but is running locally in the embedded machine, you could simply write a 
pair of wrappers, one which calls gethostbyname() and the other which 
always returns "127.0.0.1".