[Chicken-hackers] Re: Make wars

[Aleksej Saushev]

Ivan Shmakov <address@hidden> writes:

>       First of all, I know that the Autotools approach has been
>       criticized for quite a long time.  Surely, I can understand the
>       people having a hard feeling with all the bunches of
>       autogenerated code.  However, considering the initial goals of
>       the Autotools, namely, the ability to build the software on a
>       number of divergent systems, and the ability to rely on only a
>       few software packages generally available at that time, I have
>       to admit that these ``bloating'' practices were necessary.

The problem is not in it is hard to accept, it is hard to support.

When your automatically generated code fails, you have to repair it
on higher level.  In case of autotools that means learning m4 and tools 
(autoconf & stuff) in particular.  In addition, you have to deal
with original autoconf sins.  E.g. they assume that since version 3
FreeBSD advertises its object format (necessary for linking step)
through objformat tool, while that tool was meant transitional,
while converting a.out to ELF. objformat was removed, the code stayed,
autotools generate scripts in long obsolete way.  You want to bring 
handling such issues here, while it's not necessary, and there're
better ways to handle building.

>       I believe that would the portability be the primary goal for BSD
>       Make, and would only the GNU system be considered as the target
>       for the GNU Autotools, there'd rather be ``BSD Autotools'' and
>       ``GNU Make Library'', with all the problems that were raised
>       there.  Namely, the huge amount of generated code for Autotools,
>       and that one rarely sees a system-specific Make library used on
>       any other system.

There wouldn't be "BSD Autotools" for simple reason: BSD provides
the whole build system, not a single make tool, and relevant things 
are properly advertised, so that there is no need in determining them
in configure script.

>       As to why I've chosen to implement `srcdir' rather than
>       `OBJDIR', the software one's using alters the way one's
>       thinking.  I won't probably be totally wrong if I'd say that
>       I've build about 100 different packages with Autotools-based
>       build systems.  I know pretty well how these build systems are
>       used, how they're implemented, what are their gotchas, etc.
>       Hence, `srcdir' support appears to me both intuitive, simple to
>       use, and simple to implement (with GNU Make.)

I admit Sapir-Whorf thesis is applicable here. Yet there's another issue.
You may be commited to autotools and don't look for simpler alternatives,
your "srcdir" approach is hard to use: you have to create work directory,
make it current, and only then you run configure, providing srcdir.
All in the name to have source directory clean.
Yet there's simpler approach in setting the single OBJDIR variable
and forget about maintaining your build directory, creating it,
cleaning it, &c.

>       On the other hand, I've never used BSD Make, and most of my
>       knowledge about it is due to reading related materials that
>       Google brings to me and due to reading the posts like the ones
>       emerged recently in the list.
>
>       Better the devil you know than the devil you don't.

If world followed that, we'd still be using FORTRAN for all kind of things.

>       As to considering a transition to BSD Make, I'm not the one to
>       make such decision for this project.  Thus, I'm providing the
>       code for the build system currently in use.  Would the one be
>       too difficult for me to deal with, I'd cease writing patches for
>       it.  Perhaps, I'd consider making an Autotools-based one in a
>       private branch as well.

I don't propose converting to bmake, I just point that it is more useful 
(since it is easier to end user) to convert to OBJDIR concept instead of 
GNU style build directories.