On Sun, Nov 6, 2011 at 6:42 PM, Peter Karman <[email protected]> wrote: > Marvin Humphrey wrote on 10/28/11 1:09 AM: >> It may be hard/awkward/impossible to do everything we need with Make. We >> still have to run the Clownfish compiler from Perl right now, so when we get >> to that, we'll need a Perl script that we can run from Make. > > Is there anything to be gained by using autoconf and friends? > > Or asked another way, why would we *not* want to use autoconf and friends?
A couple of Linux developers recently came up with a sample library designed to show best practices: http://0pointer.de/blog/projects/libabc.html They take a strong pro-autoconf stance that I think reflects the current Linux mainstream: ---------------------------------------------------------------------------- use autotools - every custom config/makefile build system is worse for everybody than autotools is - we are all used to autotools, it works, nobody cares - it's only two simple files to edit and include in git, which are well understood by many many people, not just you. - ignore all crap autotools create in the source tree. never check the created files into git - Never, ever, ever install config.h. That's internal to your sources and is nothing to install. - And really, anything but autotools is not an option. Just get over it. Everything else is crack, and it will come back to you if you choose anything else, sooner or later. Why? think cross compilation, installation/uninstallation, build root integration, separate object trees, standard adherence, tarball handling, make distcheck, portability between distros, ... ------------------------------------------------------------------------------ In the comments, there are a few couple good arguments for CMake as a more palatable and portable alternative, but I think the authors are right that we will viewed with considerable suspicion and initial prejudice by Linux developers if we don't use autoconf for a C library. Strangely, I think it's actually permissible if the actual Makefile calls out to Perl and Charmonizer (and to build Charmonizer), but for acceptance this should be hidden behind a layer of "configure && make && make install". I'm not sure what the Windows perspective looks like, but I fear it might not be compatible with this view. Can any of the new additions to this list offer that perspective? And what works well for OSX? --nate
