[Chicken-hackers] Re: Make wars

[Aleksej Saushev]

Ivan Shmakov <address@hidden> writes:

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

That's your right.

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

Any high-level tool may be misapplied.

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

You have to learn it anyway.  What is the most annoying, it is
yet another tool with yet another similar but a bit different syntax.

>  > 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 don't know how FreeBSD porters deal with it. Ask them.

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

Does GNU Make provide any of them?
Or does it depend on 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 

_make clean_

If you like to complexify it, others don't.

echo OBJDIR=/path/to/objdir >> ../Makefile.inc
and forget it, you don't need to write it each time, 
everything reduces to "nohup time make &" and "make clean".

I put OBJDIR assignment to my mk.conf, and _never_ write it,
BSD build system does it for me. For each project.

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

It makes big difference, if you don't complexify BSD usage case.

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

Bootstrap pkgsrc? Never tried.
There's simple way to do that natively using Interix. I did that.

>  > cleaning it, &c.
>
>       I don't understand.  Does BSD Make remove the build directory
>       for you?

I understand it pretty well.
As I told earlier, yes, make clean removes object directory.

By the way, GNU way doesn't allow that, since you're forced to
chdir into object directory.

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

One's expected to understand, whether the tool is needed at all.

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

In short, it just slows everything down and doesn't cover actual
portability issues. In addition, it masks actual problems of not
detected yet present and wanted libraries.  It tries to cover
tasks of package system, yet it's not package system, and it
fails to replace one.


-- 
CKOPO CE3OH...