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

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

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

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

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

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

[...]

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

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

        Certainly, when you have just one build directory it won't be
        possible.

[...]

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

[...]

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

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

[...]

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

        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:

        * the use of [the build system] for the user (covering, e. g.,
          the use of --prefix="$HOME", $ make & $ make install, et
          cetera);

        * the same for the system administrator (mentioning using su(8)
          or sudo(8) to do # make install);

        * the same for the developer (covering creating control files
          for the build system, building several versions of the code
          from the same source tree, et cetera);

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

        * the same for unordinary packages (covering, e. g., running
          LaTeX and Gnuplot from within the build system, etc.)

        I'd need the texts under a license not stricter than GNU FDL,
        preferrably both in English and in Russian.

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