[Chicken-hackers] Re: Make wars

[Aleksej Saushev]

Ivan Shmakov <address@hidden> writes:

>>>>>> Aleksej Saushev <address@hidden> writes:
>
> [...]
>
>  >>> 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.
>
>       Yes.  Is that a problem with that tool?

Yes. Its use don't outweigh its drawbacks.

>  >>> 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.
>
>       Even when not using GNU Autotools?

Right, not using autotools you avoid learning one more text preprocessor
and one (or two) more conventions in writing build scripts, with all
their idioms, patterns, and best practices.

>  > What is the most annoying, it is yet another tool with yet another
>  > similar but a bit different syntax.
>
>       I've heard of Scheme being depicted as (not literally, but
>       rather close to) ``yet another Lisp, with yet another similar
>       but a bit different syntax.''  Is that a problem with Scheme?

Bulgarian is yet another Russian with "yet another similar but a bit
different grammar and lexicon."  Overstating isn't helpful.

The problem with m4 is that it uses similar denotations, but with a bit 
different semantics.  For instance you use Latin-derived words in Russian,
which are adopted with a bit changed semantics. The latter leads to bugs.
The most common mistake is using "practically", which means "in practice" 
("na praktike", "na dele"), not "almost" ("pochti").  Sometimes it doesn't 
matter, when you have the precise understanding, what the hell is going on,
sometimes it is confusing.

>  >>> 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,
>
> [...]
>
>  >> 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 mean, was the bug reported to the GNU Autotools developers?
>       And if it is, could you point me to the discussion spawned by
>       that report?

No, I didn't. I am sick of those tools and issues they bring, so
I leave it to others.  If you want more details, try common packages
on FreeBSD 7.  I don't remember announcement, thus it may not have been
released, but there're testing or pre-release versions around.
What makes the problem worse, is that not all packages expose it.

>       Certainly, the maintainers shouldn't be forced to deal with the
>       bugs in the software.  Rather, the bugs should be fixed.

I've seen many ad hoc patches to those automatically generated configure
scripts, and I created them too.  My opinion is that in many cases
autotools are just unuseful but to make life more interesting and diverse.
If you want to fix bugs, you'd better avoid autotools and go not producing
any related bugs at all.

>  >>>> 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'',
>
> [...]
>
>  >>> 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:
>
> [...]
>
>  >> 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?
>
>       The latter.  Hence it needs GNU Autotools to check for which
>       features are provided by the host system components.

And when no tool is found, what does it print?  One line amoung thousands,
which ends in "... no".  "make" does it more straightforward way: it reports
line number in Makefile, and the name of command it couldn't run, thus 
being more helpful in finding the problem. If you want to check your tools,
you need test suite for them, and that's quite another issue:
GNU folk is generally unable to write portable code, they use GNU tools, 
and other tools work more accidentially, since they don't rely on extensions.
It brings another reason for not using autotools: if most of tools checked 
are GNU provided, then there's no reason to recheck them in build time, 
it's just a waste of time.  If they wanted to really _check_ prerequisites,
they'd have provided separate testing script, not the guessing one.
So that it reported "you wanted XXX, but your YYY doesn't provide necessary
features, use compatible YYY, e.g. the one from ZZZ, or don't ask XXX at all."

> [...]
>
>  >>> 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?
>
> [...]
>
>  > _make clean_
>
>  > If you like to complexify it, others don't.
>
>       It seems that you've missed the point completely.  My intent is
>       to be able to perform several builds at the same time (either to
>       use different options, or to specify different host systems, or
>       just to test the things being built correctly for a particular
>       just-imagined case.)

export MAKECONF=/your/another/mk.conf

Now you work with another configuration for the whole session or
until you unset or change MAKECONF value.  It's not a problem
in having several configurations, I did that for custom FreeBSD
installations (routers).

Advantage of this very approach is you need to study that very
make tool and shell you're using now, and nothing else, except
for provided scripts.  No m4 is involved.

>       Take a look at my recent post here about bootstrapping Chicken
>       and then immediately cross-compiling it.  (I'm now thinking
>       about a Shell script to cross-compile Chicken for every
>       supported platform, mainly for the testing purposes.)

BSD build system supports cross-builds.

> [...]
>
>  > I put OBJDIR assignment to my mk.conf, and _never_ write it, BSD
>  > build system does it for me. For each project.
>
>       As I've stated above, I need a directory per /build/.

And it's not a problem to write it once per session:

export OBJDIR=there

>  >>> 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.
>
>       Current Chicken build system is based on GNU Make alone and I'm
>       not going to discuss whether it should be changed or not (since
>       I'm not the one to decide it.)
>
>       What I was asking was how do you create the $(OBJDIR) directory
>       from within the Makefile when building on a bare MinGW / cmd.exe
>       system?

I never used MinGW, since it never fitted my needs. Yet gmake requires 
/bin/sh, and GNU autotools still require mkdir present, don't they?
So what's the point in your question?  Bare MS Windows doesn't provide
any POSIX development tools at all, so what?

>  >>> 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.
>
>       Indeed.  That seems to be a matter of a simple script, though.

So that you build not with "make" command but with you custom build script,
what's the point of your proposed changes then?
You could have extracted source in separate directory, applied
your custom patches and so on, like pkgsrc does.
What's the point in having autoconf?
What technical needs does it cover?
Does it worth maintanance efforts?

If I were you, I'd propose further build system simplification rather, 
so that to avoid unnecessary complex steps like configure, which are 
hard to override, if they do anything contrary to your expectations.

>  > 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.
>
>       Well, I wasn't talking about such a concise description.
>       Actually, I'm planning to put some examples on using GNU Make,
>       GNU Autotools and possibly other build systems, along with the
>       descriptive texts, and a rough list of the advantages and
>       disadvantages of them pertinent to their respective designs at
>       [1].  Since I know way too little about BSD Make, I'd appreciate
>       someone having a better experience with it to write it for me.
>
>       The structure would be roughly as follows:
>
> [...]

Everything is covered in manual pages, READMEs, PSD, and guides.

We have separate build system (bsd.*.mk scripts, bundled with the
operating system) and package system (build part is shipped separatly,
as it is cross-platform, tools are incorporated into operating system).

>       * the same for the package maintainer (covering basics of the
>         build system and the packaging system interoperation, if
>         applicable);

You want to represent GNU autotools as package system, but they don't
provide the one.  Source tarball is not a package or a very bad one,
since it doesn't provide neither binary installation, nor any clean 
way of upgrade (either binary or source).

> [1] http://theory.asu.ru/~ivan/doc/


-- 
CKOPO CE3OH...