[Chicken-hackers] Re: Make wars

[Ivan Shmakov]

>>>>> Aleksej Saushev <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.

        I disagree.

 > When your automatically generated code fails, you have to repair it
 > on higher level.

        Indeed.  But doesn't the same apply to the use of any other
        higher-level tool?

 > In case of autotools that means learning m4 and tools (autoconf &
 > stuff) in particular.

        I'm somewhat familiar with M4.  At least, I was able to
        implement both the simplistic loops and arrays in it.
        Fortunately, Autoconf doesn't require learning such tricks.

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

        Could you point me the discussion related to this Autoconf bug?
        What was the ``official'' resolution given to the case?

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

        The GNU Coding standards ``define'' the build environment as,
        roughly, Make, C compiler and the related tools, and the
        following programs:

--cut: (standards) Utilities in Makefiles--
     cat cmp cp diff echo egrep expr false grep install-info
     ln ls mkdir mv pwd rm rmdir sed sleep sort tar test touch true
--cut: (standards) Utilities in Makefiles--

        Does BSD Make provide all of the above, or it depends on (most
        of) these being provided by the host system?

 >> As to why I've chosen to implement `srcdir' rather than `OBJDIR',
 >> the software one's using alters the way one's thinking.

[...]

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

        Certainly.

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

        Does the following example show the generic cases of using
        either?

$ cd builds/ 
$ mkdir gnu-project-build && cd gnu-project-build/ 
$ /usr/src/gnu-project/configure [...] 
...
$ LC_ALL=C nohup time make & 
...
$ [...]
$ cd .. && rm gnu-project-build -rf 
$ 

$ cd /usr/src/bsd-project 
$ LC_ALL=C nohup time make OBJDIR="$OLDPWD"/builds/bsd-project-build & 
...
$ [...]
$ rm "$OLDPWD"/builds/bsd-project-build -rf 
$ 

        Hardly it makes a difference; either way the user is expected to
        specify the locations of both the source and build trees.
        Rather, there could be either a script, or a Makefile part, to
        ``convert'' `srcdir' into `OBJDIR' and vice versa.

 > Yet there's simpler approach in setting the single OBJDIR variable
 > and forget about maintaining your build directory, creating it,

        So, the build system is expected to create the directory for
        you.  Is there a simple way of doing this on a bare MinGW
        system?

 > cleaning it, &c.

        I don't understand.  Does BSD Make remove the build directory
        for you?

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

        Not at all.  My point is that one's expected to learn (/know/)
        the tool one's using.

[...]

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

        I see no difference.  I would be satisfied with either approach
        being available for Chicken.

        [I'm going to continue this discussion privately.  I'm quite
        interested in comparing GNU Autotools with BSD Make and I'm
        going to send you a few more questions off the list.]