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".
