Compilation setup (Was: Modules)

[Hans Aberg]

On 20 May 2008, at 04:42, Han-Wen Nienhuys wrote:

> > My original reply was to Karl Hammar said:
> >
> > > I would be nice to be able to do like
> > >
> > >  lilypond a.ly .. o.ly z.ly
> > >
> > > i.e. treat a.ly .. o.ly as if they where included in z.ly, without
> > > having to say so in z.ly.
> >
> > to which I said it is not needed with the Haskell system. But I  
> > think there
> > were some discussions about making it easier to share code, just  
> > set some
> > local fonts.
>
> I wouldn't be against a -dconcat-args flag, which would concat all the
> argument contents and then run lily over the result.
>
> You have to keep in mind though, that this make life more difficult
> for others if you ever ship your .ly files to others.

I felt this, too, that it would lead to C-like setups, which are  
complicated to maintain. In Haskell, one can write
  ghc --make A.hs
where A.hs contains a top node "main".

C and Haskell have in common that one can produce separate object  
code components which can be linked together later, thus saving  
overall compile time. So if Lilypond could produce (if usable)  
separate compiles (like score sections or part) which later are  
linked together, then each such unit might be a module. Then I think  
the Haskell system, where each file from within contains the  
information for a complete compile, is simpler to use.

Haskell has a default module "Prelude", which can be removed by  
importing it explicitly. So also in this case, a startup command for  
removing it is unnecessary.

If people want to share code, and find it difficult to pick together  
package, the idea of a lilypond --make-package comes to my mind.  
Instead of producing a PDF, it would pick together say a .tgz package.

  Hans Åberg