Re: Moving away from make

[Graham Percival]

On Sat, Sep 24, 2011 at 10:41:05PM -0300, Han-Wen Nienhuys wrote:
> On Sat, Sep 24, 2011 at 10:05 PM, Graham Percival
> <address@hidden> wrote:
> > This didn't happen for fun and giggles.  Over the years, we've
> > built up hack upon hack, and ended up with this unholy mess.
> 
> You sound spoiled.

Why, because I think it's not perfect?  How many discussions, how
many developer-hours, have we spend talking about build problems
on this list?  How much frustration and wasted time/goodwill have
we spent on those problems?

Despite that, I'm not advocating a move away from make; it would
take us about 200 hours to reach merely the current level of build
system-ness.  There are far more important things to work on --
but I'm not going to pretend that the status quo is great, nor do
I think it's silly to ask about switching to a different system.


I will admit there is one aspect in which I *am* spoiled, though:
I am totally spoiled by python's readable code.  I am so
accustomed to writing stuff like
    cmd = compiler + ' -o ' + exe_name + src_files
or
    cmd = "%(compiler)s -o %(exe_name)s %(src_files)" % locals()
that I find stuff like
    $(CC) -o $@ $<
silly.  The readability for casual contributors -- which is what
most people looking at build system stuff are -- is ridiculously
better in python than anything else.

> * The build scripts are not really part of the complexity of the
> build system.  They are normal programs, they are just not
> intended to be run by end users.  I assume you are not
> considering a rewrite of output-distance.py in CMake's scripting
> language.

True.  OTOH, there is certainly complexity in there that we don't
need -- AFAIK we don't use bib2html.pl any more; we instead ose
bib2texi.py.  So we could remove the perl file from the
GNUmakefiles, and even remove the script entirely from our source
tree.

It's stuff like that which bugs me.  Some time down the road,
somebody will be trying to fix some bug in the bibliography, and
they'll spend hours looking at bib2html and the files it produces,
before finally discovering that it's not actually used.

> * You make 5000 lines of makefile sound as if it is a lot.  I think
> you should look at other packages' build systems more closely.
> 
> For example, coreutils, which is 70k lines of C, and a trivial
> documtentation and test process has, count'dem: 2000 lines of
> Makefile.am.
>
> This is for just linking together a bunch of bog-standard C object
> files, generating an info page, and running some shell scripts as
> tests.

Wow.  That's insane.

> I think 5k lines is pretty impressive for a package as complex as
> LilyPond, considering that it has a bizarre documentation process,
> translated docs, python bindings, fonts that are run through metapost
> and fontforge, a complex regression test, and needs weird acrobatics
> to find its gazilion different init files.

It's certainly impressive, and it could definitely be worse.
But it's not easy to maintain.  At least, it's not easy to
maintain for casual developers like me.  I'd be overjoyed if
somebody non-spoiled and non-stupid (i.e. not me) offered to step
forward and fix the known problems with the build system.

Cheers,
- Graham