[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.
>
>       Are you still talking about the use of ``any high-level tool''
>       here?  I could hardly argree on that.

Yes.

Be precise, what high-level tool you find useful in context?
Autoconf? Cmake? Jam? What else?

>  >>>>> 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.
>
>       Well, what are the other ``text preprocessors'' you keep in mind
>       saying this?  M4 is the only tool in this niche I do know about.
>       Other macro processing systems known to me (namely, Cpp and TeX)
>       are rather specialized.

What makes you think that other text processing tools, like sed or awk, 
don't fit the needs?  In addition, there's other historical tools.

>       And yes, I do need a generic ``text processor'', and it even
>       helps me to earn money.  So far I've used M4 and it fitted
>       nicely for me.

I've never seen m4-related positions, not even autoconf ones,
XSLT is the only text preprocessor demanded on labour market,
and it is XML-specialised.

>  >>> What is the most annoying, it is yet another tool with yet another
>  >>> similar but a bit different syntax.
>
> [...]
>
>  > The problem with m4 is that it uses similar denotations, but with a
>  > bit different semantics.
>
> [...]
>
>  > Sometimes it doesn't matter, when you have the precise understanding,
>  > what the hell is going on, sometimes it is confusing.
>
>       I guess, the above applies only to the use of M4 in Autotools,
>       not to any other cases?

Not only to m4 but to the whole automatically generated script,
since it relies on dumb guesses like shown earlier.

>  >>>>> In addition, you have to deal with original autoconf sins.
>
> [...]
>
>  >>>> 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.
>
>       You mean you've found the bug, but didn't report it?  How do you
>       expect it to be fixed then?

It is reported.

And it is well-known that this is design bug of the whole autoconf thing.

> [...]
>
>  >>>>>> 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,
>
>       ... after taking 12 hours to reach that line...

Do you spend 12 hours loading the relevant Makefile into text
editor and getting to relevant line?  Contrary to configure scripts,
make doesn't mask errors.

>  > thus being more helpful in finding the problem.
>
>       I'd not call that helpful at all.

You find it more helfpul getting "no" somewhere in 1000-line long 
configure log and failing during build stage, when error message
points into machine-generated file with machine-generated code, right?

>  > 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,
>
>       Do you use GCC?  Do you use it non-GNU systems?  And if so, how
>       could you accuse its authors for being unable to write portable
>       code?

I use it and it occasionally fails. So?
Even more, when it fails, you can't even guess, what the hell is going on,
since it works without any optimisation and not with turned on.

>  > 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.
>
>       Indeed, there's almost no reason to use Autotools in
>       non-portable programs.

There's no reason in using Autotools in portable programs too.

>  > 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."
>
>       That's exactly what `configure' is supposed to do.
>
>       I'm not sure what you mean by ``guessing'', but I think it's not
>       ``guessing'' that was the design goal for GNU Autotools.

I don't speak for how it is supposed to be, I speak about how it works.

> [...]
>
>  >> 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
>
> [...]
>
>  > 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.
>
>       Unfortunately, as I've mentioned above, I need M4 anyway.

So, you're addicted to m4 and can't even imagine the life without it.

>  >> 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.
>
>       But the current Chicken's build system isn't based on it.

Neither on Autotools.

> [...]
>
>  >>> 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:
>
>       (Or, rather, once per build.)

You can perform as many sequential builds in that directory as you wish.

>  > export OBJDIR=there
>
>       So, there's no huge improvement over the `srcdir' approach in
>       this particular case.

There's big improvement, since you don't need unobvious steps in
setting up build directory and moving around.

> [...]
>
>  >> 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,
>
>       Does it?  Are you speaking out of experience, or just guessing
>       here?
>
>       I really do not know whether /bin/sh is necessary, but the use
>       of the `type' command in the one of the Chicken's makefiles
>       suggests that it's `cmd.exe' that it's used, and not `/bin/sh'.

If it doesn't, it is gmake's failure in being non-compliant:

 <<Command execution shall be as if the makefile command line were the
 argument to the system() function.>>

 <<The environment of the executed command shall be as if a  child process 
 were created using fork(), and the child process invoked the sh utility 
 using execl() as follows:

   execl(<shell path>, "sh", "-c", command, (char *)0);>>

SUSv3 aka POSIX.

>       (I'm pretty sure that the most of the Chicken folks here have
>       already put the Subject: into their respective killfiles to stay
>       forever, but I'd be glad if someone could clarify on this.)
>
>  > and GNU autotools still require mkdir present, don't they?
>
>       But the current Chicken's build system isn't based on GNU
>       Autotools, either.

And I'm pretty satisfied with it, you're not.

>  > So what's the point in your question?  Bare MS Windows doesn't
>  > provide any POSIX development tools at all, so what?
>
>       MinGW provides GCC, Binutils and the necessary libraries and
>       header files.  The only other requirement of the current Chicken
>       build system, IIUC, is GNU Make.  No POSIX development tools
>       beside of the above are necessary to build Chicken.

I have to repeat: so what was the point in your question?

And once more: what is the point in your proposal to use autotools?

>  >>> 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,
>
>       Well, yes.  Would you be surprised to know that I use a custom
>       script to build Chicken extensions, rather than using
>       chicken-setup(1) directly?

It's your right.  So what?  You're forcing others to use autoconfed build 
system without any real need.  At least you've failed to prove that.

>  > what's the point of your proposed changes then?
>
>       What changes?

So, you have forgotten why the discussion started.

>  > 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?
>
> Autoconf is used to collect the build options specified by the user,

It is done with config.h or passing options to make as well,
autoconf is not needed for this at all.

> to test the build environment for being suitable for building
> this particular program

How does it perform?  Only build itself shows it in fact.
How does it report errors?  You need really good intuition to
understand that sometimes.

What it does, it performs yet another similar check that my platform 
is NetBSD or FreeBSD, that my cc is gcc, and it's working. I never
knew that! Very useful information to recheck one more time.

> (and with the particular build options),

It is hard to make it believe that I have proper though nonstandard
installation ("CFLAGS+= -I../i/have/it/here" would do the trick),
it masks errors of badly detected library absense, it silently 
adds options, which are advertised only in its input file or
lengthy machine-generated configure script.

> and to notify the build process about the build environment gotchas,
> if any.

It fails in this, like it is shown recently with objformat bug.

In addition, it requires that you fix bug in autoconf or configure.ac,
while the obvious way is to fix it in makefile, config.h or environment.

>  > Does it worth maintanance efforts?
>
>       I believe it is.

I don't believe and even have proofs of that, though I don't need to
prove anything in this case.

>  > 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).
>
>       Unfortunately, I have not much time to invest in learning the
>       build systems I'm not going to use in the any near future.  If
>       anyone is interested in writing about the BSD build and
>       packaging systems, I'd be happy to put it on my doc/ pages.  But
>       if there's none, I'd not probably bother doing it myself.

And you expect others to invest their time in learning the build system,
which has serious design flaws, masks it's own errors showing them in
quite another layer, and otherwise makes users' life more "interesting".


-- 
CKOPO CE3OH...