Graham Percival <gra...@percival-music.ca> writes: > 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 >> <gra...@percival-music.ca> 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?
The main problem I see is that dependencies don't work out, and that presumably is mostly because the temporary/work files of lilypond-book are not in the rules and get stomped over by parallel make. We need to get this fixed in order to be able to use big bad multicore machines for automated building, testing and bisecting. "Cross fingers and retry" is nothing you want for automated work. > 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. I don't do Python or many newfangled languages. I have worked with Make for over 20 years. The casual contributor will be one used to the technology and thinking underlying Lilypond. More likely than not someone with more than a trace of free software project experience in them. I guess that at least 98% of all free software projects use Make for its build system. Make is not the problem. The problem is managing the Makefiles once you start writing them automatically. Then you have another layer. How much of this layer simplifies things, how much complicated them? Do we need it at all? Probably the main thing that needs to be outsourced is the intelligent handling of lilypond-book/snippets. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
