I have to admit libtool and autoconf suck big time when it comes to simple "self-contained" packages. Libtool fails miserably if your ld is not gnu, and autoconf fails if c++ compiler does not know cpp suffix (.cc is more common). If we had a simple plain Makefile it wouild be non-issue.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I disagree that a "simple plain Makefile" would be better. The minute that you start wishing to provide and and link against dynamic libraries on multiple platforms, CPU architectures and operating systems a "simple" makefile doesn't stay simple for long.
If you wish a project to be accessible on multiple platforms "out of the box" you need to make some sort of decision as to the to the top level build construction environment you are going to use. Alternatively you decide that you are going to personally provide support/collate/maintain makefile variants for all the platforms on which your software is used.
I decided that for the CLISH project there was no point in replicating the work of many pre-existing build meta-tools:
autoconf, jam, bjam, Cmake are just a few that spring to mind.
I chose to use autoconf as it seemed to the most commonly used in most the opensource projects I'd used. I agree it's a bit quirky but
- it does produce sensible full-dependancy makefiles (avoiding the use of recursive make).
- It is also the "recommended" means for packaging for the GNU project…
- it provides single line production and verification of a package distribution "make distcheck"
- can be used to automatically run package checks (unittests)
- provides hooks for configuration time choices for the kind of package you wish to build
It also (through the use of the shell script based "configure" file) doesn't require the person installing the package to have installed a particular build construction system ("configure" doesn't require autoconf to be installed to build a package)
The most recent package drop which I made to sourceforge (http://sourceforge.net/projects/clish/files/lub/lub-0.7.4/lub-0.7.4.tar.gz/download) was a subset of the CLISH project, which doesn't use autoconf but uses BJAM (the same envrionment used by the BOOST libraries). This does require the installation of the bjam environment, hence doesn't work "out-of-the-box" (although it's not difficult to install) I did this as a bit of an experiment to see how easy this system was to use.
Another system which I've used at work is CMake (which has the advantage that it can generate UNIX makefile or Windows VC++ project files)
At the end of the day, I do not think that it makes sense to use a multiplicity of meta-build tools on the same project, so I'm happy for clish to continue to use "autoconf".
If you wish to construct your own makefiles to build the various modules for your own environment and target platform, then you're welcome to do so. (I did this at a previous employer to build and link with VxWorks.) But any such makefiles are going to be platform specific and not easily adapted to support multiple target environments.
best regards
Graeme
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am still sure that "simple" makefiles are still simple for projects of that size. Get rid of auto tools and configuring for any given system takes less than a minute; fixing fscked up autoconf, libtool and other crap may take *days*.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Have a look at OpenFWTK, project that I maintain. It is really that simple. No heuristics, no "duplication of work" because there is no need of such "work". A few templates is better than trying to be "smart" and failing with it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have to admit libtool and autoconf suck big time when it comes to simple "self-contained" packages. Libtool fails miserably if your ld is not gnu, and autoconf fails if c++ compiler does not know cpp suffix (.cc is more common). If we had a simple plain Makefile it wouild be non-issue.
Hi Akenoi
I disagree that a "simple plain Makefile" would be better. The minute that you start wishing to provide and and link against dynamic libraries on multiple platforms, CPU architectures and operating systems a "simple" makefile doesn't stay simple for long.
If you wish a project to be accessible on multiple platforms "out of the box" you need to make some sort of decision as to the to the top level build construction environment you are going to use. Alternatively you decide that you are going to personally provide support/collate/maintain makefile variants for all the platforms on which your software is used.
I decided that for the CLISH project there was no point in replicating the work of many pre-existing build meta-tools:
autoconf, jam, bjam, Cmake are just a few that spring to mind.
I chose to use autoconf as it seemed to the most commonly used in most the opensource projects I'd used. I agree it's a bit quirky but
- it does produce sensible full-dependancy makefiles (avoiding the use of recursive make).
- It is also the "recommended" means for packaging for the GNU project…
- it provides single line production and verification of a package distribution "make distcheck"
- can be used to automatically run package checks (unittests)
- provides hooks for configuration time choices for the kind of package you wish to build
It also (through the use of the shell script based "configure" file) doesn't require the person installing the package to have installed a particular build construction system ("configure" doesn't require autoconf to be installed to build a package)
The most recent package drop which I made to sourceforge (http://sourceforge.net/projects/clish/files/lub/lub-0.7.4/lub-0.7.4.tar.gz/download) was a subset of the CLISH project, which doesn't use autoconf but uses BJAM (the same envrionment used by the BOOST libraries). This does require the installation of the bjam environment, hence doesn't work "out-of-the-box" (although it's not difficult to install) I did this as a bit of an experiment to see how easy this system was to use.
Another system which I've used at work is CMake (which has the advantage that it can generate UNIX makefile or Windows VC++ project files)
At the end of the day, I do not think that it makes sense to use a multiplicity of meta-build tools on the same project, so I'm happy for clish to continue to use "autoconf".
If you wish to construct your own makefiles to build the various modules for your own environment and target platform, then you're welcome to do so. (I did this at a previous employer to build and link with VxWorks.) But any such makefiles are going to be platform specific and not easily adapted to support multiple target environments.
best regards
Graeme
I am still sure that "simple" makefiles are still simple for projects of that size. Get rid of auto tools and configuring for any given system takes less than a minute; fixing fscked up autoconf, libtool and other crap may take *days*.
Have a look at OpenFWTK, project that I maintain. It is really that simple. No heuristics, no "duplication of work" because there is no need of such "work". A few templates is better than trying to be "smart" and failing with it.