Anselm R Garbe wrote:
What about the good old way of providing one master makefile for each
platform instead of these scripts that are doomed to fail anyways
sooner or later?
It's not only about platform, for small projects i find single makefiles ok,
but for big ones you need to separate the configuration/build steps, because
you need to get information about which libraries, include files, programs,
etc.. are in the system. In some situations just create a .mk file with such
information, but you will probably need to export some of the information
into a .h file.
Sometimes the configuration step is not as simple as run this and tell me
if it works or not. This makes a shellscript much more manageable than
a makefile, because it's not a task of the make and you end up forking from
make which is inneficient and ugly to maintain.
About having one different mk file for each platform..well I always find
anyoing
to have to maintain N files that does the same, or for building..it's a mess
for packaging because there's no standard on this, and automatize the
build or do some packaging becomes a mess.
You get the package and you have to spend few seconds to identify which
makefile you have to use, and then if you get compilation errors you have to
guess which dependencies are missing. then you can try to find INSTALL or
README files to see whats missing or try to fix the program if you get that
its not a dependency problem. So this makes the build process simpler, but
less error-prone and more annoying for packagers and users.
The only good thing from autotools is that they are the standard, and this
hardly simplified the steps of development, packaging, compilation and
deployment. This is: make dist, make mrproper, automatic detection of
file dependencies, check for dependencies, etc.
For suckless projects i dont find logic to use such a monster, but for big
projects it is many times a must. Because you end up with conditional
dependencies, recursive checks to ensure consistence of a program, etc.
If you have a build farm or any massive-compilation environment, you expect
that all the packages are going to build and react in the same way. But this
is not true. There are some basics in the software packaging that not
everybody understand or know.
Things like sand-boxing installation (make DISTDIR=/foo), cross-path
compilation (VPATH),
optimization flags detection for compiler, make dist, etc. are things
that many of the
makefile-only projects fail to do. I'm not trying to say that those are
things that all
packages must have, but it's something that standarizes the build and
install process,
and simplifies the development and maintainance.
I wrote 'acr' because i was looking in something ./configure-compatible,
but lightweight
and simpler to maintain than the m4 approach. It works for me quite
well, but I try to
only use it for the projects that really need to split the build in two
steps. For building
in plan9 I just distribute a separate mkfile which doesnt depends on the
configure stage.
But plan9 is IMHO a quite different platform to not try to support it
from the acr side,
because the makefiles should be completely different too.
--pancake
