Re: Moving away from make

[Graham Percival]

On Fri, Sep 23, 2011 at 07:08:26PM +0200, address@hidden wrote:
> Hi,
> 
> On Fri, Aug 12, 2011 at 02:53:56PM +0100, Phil Holmes wrote:
> 
> > I understand it's been discussed before, but I am wondering whether
> > it's worth thinking the unthinkable and considering moving away from
> > make.  I know it's been used in loads of projects and is much loved,
> > but actually, from a design perspective, it's appalling.
> 
> I don't understand why so many people think it is... The Make language
> as it stands does have some quirks, but I like the fundamental concept.

That's like saying "java has some quirks, but I like the
fundamental concept of architecture-independent interpreted code
and just-in-time compilers".  There's an order of magnitude
between ease of programming in python and java.

> But of course that's mostly irrelevant anyways when using a Makefile
> generator such as Autotools...

Phil was using the term "make" to refer to our stepmake system,
which is on top of autotools, which (of course) is on top of
actual make(1).  Yes, this is technically incorrect, but I think
that's a relatively small nit to pick.

> > If I was writing a "make" system from scratch, I would describe
> > dependencies in data structures that are viewable and editable, and
> > have a separate program that uses those structures to determine which
> > files need making.
> 
> I'm not sure why you need extra structures for that? For C/C++, gcc can
> figure out the dependencies as a side effect of compiling the normal
> source code; and this can be done for most other languages as well. Very
> few non-trivial programs actually maintain their dependencies by hand
> nowadays...

That's a great comfort for our lilypond texinfo documentation,
which *does* require explicit dependencies.

As far as I know, every single build system has trivially easy
support for C/C++ compilation.  That's not an issue.  The issue is
building documentation, building swig python modules (for me
personally, not lilypond), generating translations, generating
test cases and automatically showing potential problems, etc.

According to
  find . -name "*.make" -or -name "GNUmakefile*" | xargs cat | wc -l
we have 5059 lines of build-system stuff.  Actually, that's not
counting python helper scripts:
  wc scripts/build/*.py -l
4113 total

So... 9171 lines of build-system junk.  I think this meme is
appropriate:
  It's over NINE THOUSAND!!!

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.  Is
that purely the fault of autotools?  No.  Could it be *worse* if
we used a different build system?  Sure.  But it could also be
*better* if we used a different build system.

> > I've done 5 minutes research and have found SCons.  I've not gone into
> > any more depth with that yet.  Does it seem worth looking into this,
> > or something else, in more detail?
> 
> I don't know about SCons, but at least the often-proposed Cmake is *not*
> a Make replacement. It's a Makefile generator, just like Autotools.

Yes, but it's still a different *build system*.  Our interaction
with the build system would take the form of CMakeLists.txt files.
Would that interaction result in a more maintainable system, i.e.
one which does not have a powerlevel of OVER 9000?  Probably yes.

What's uncertain is how much work would be involved in switching
to that (or any other) build system, vs. how much better that
would make matters,

Cheers,
- Graham