[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Moving away from make
From: |
Han-Wen Nienhuys |
Subject: |
Re: Moving away from make |
Date: |
Sat, 24 Sep 2011 22:41:05 -0300 |
On Sat, Sep 24, 2011 at 10:05 PM, Graham Percival
<address@hidden> wrote:
>> > 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.
You sound spoiled.
* 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.
* 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.
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.
--
Han-Wen Nienhuys - address@hidden - http://www.xs4all.nl/~hanwen
- Re: Moving away from make, olafBuddenhagen, 2011/09/24
- Re: Moving away from make, Graham Percival, 2011/09/24
- Re: Moving away from make,
Han-Wen Nienhuys <=
- Re: Moving away from make, Graham Percival, 2011/09/24
- Re: Moving away from make, Graham Percival, 2011/09/24
- Re: Moving away from make, David Kastrup, 2011/09/25
- Re: Moving away from make, Graham Percival, 2011/09/25
- Re: Moving away from make, David Kastrup, 2011/09/25
- Re: Moving away from make, Graham Percival, 2011/09/25
- Re: Moving away from make, David Kastrup, 2011/09/25
- Re: Moving away from make, Han-Wen Nienhuys, 2011/09/25
- Re: Moving away from make, Karl Hammar, 2011/09/25