[Chicken-hackers] Re: Make wars

[Ivan Shmakov]

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

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

        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.

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

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

[...]

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

 > thus being more helpful in finding the problem.

        I'd not call that helpful at all.

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

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

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

[...]

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

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

[...]

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

 > export OBJDIR=there

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

[...]

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

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

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

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

        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?

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

        What changes?

 > 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, to test the build environment for being suitable for
        building this particular program (and with the particular build
        options), and to notify the build process about the build
        environment gotchas, if any.

 > Does it worth maintanance efforts?

        I believe it is.

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

        If they do anything contrary to my expectation, then there's a
        bug.  Either in the `configure' script, or in my expectations.

        (And the bug in the `configure' script either comes from
        `configure.ac', or from Autoconf itself.  Not a big deal to fix
        it in either case.)

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

        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.

 >> * 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,

        No, I don't.  Honestly.  Rather, I'd write about the use of a
        GNU Autotools-based build system along with a packaging system,
        such as the Debian one.

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

        Yes.