Re: Identify included files

[David Wright]

On Thu 21 May 2020 at 17:54:38 (+0100), antlists wrote:
> On 21/05/2020 16:36, David Wright wrote:
> > On Thu 21 May 2020 at 13:57:00 (+0100), antlists wrote:
> > > On 21/05/2020 01:49, David Wright wrote:
> > > > I don't understand your equivalence between .ily and .h files. The
> > > > .ily file(s) can contain just as much code as the .ly file(s), whereas
> > > > .h files don't contain any code at all (in the sense of producing
> > > > executable code for the next stage.
> > > 
> > > a) just like .h files, .ily files can't be passed directly to a
> > > compiler for compilation.
> > 
> > Why do you say that?
> 
> Because while it may not be globally true,

It's not true at all.

> I have tried accidentally
> to do things like "lilypond voiceTrombone.ily" and it blew up quite
> spectacularly. I would expect most of mine, and in truth most other
> peoples', .ily files to blow up if fed straight to lilypond.

Big deal. I won't ask what's in voiceTrombone.ily.

> And if they do compile, the output probably isn't much use ... :-)

That depends on what output you're expecting, and whether the file
conforms to the expectations of the person compiling it. By that
I mean that it's possible for anybody to name any file quz.h or
quz.ily and then say "Gosh, look what happens when I compile it!".

Here I am compiling clockchips.h from the linux kernel:

$ gcc clockchips.h 
$ ls -lgG clockchips*
-rw-r--r-- 1    7445 Apr 23 03:30 clockchips.h
-rw-r----- 1 1790384 May 21 20:01 clockchips.h.gch

No output on the terminal is good news. I see that a pre-compiled
header has been generated.
Here I am compiling an .ily file pasted from the LM:

$ ~/lilypond-2.21.0-1.linux-64/bin/lilypond definitions.ily 
GNU LilyPond 2.21.0
Processing `definitions.ily'
Parsing...
definitions.ily:1: warning: no \version statement found, please add

\version "2.21.0"

for future compatibility
Success: compilation successfully completed
$ ls -lgG definitions*
-rw-r----- 1 575 May 21 19:50 definitions.ily
$ 

> > > b) who says .h files don't produce executable code? They often contain
> > > code, sometimes entire functions.
> > > 
> > > I understand the equivalence exactly - it's what you DO to the file.
> > 
> > Good, that means I have a second source of edification as to what the
> > intent of this analysis is.
> > 
> > > You're thinking "what you *should* put in the file". Since when have
> > > people done what they *should*?
> > 
> > Letting that pass, let's say we have a source file foo.c and it needs
> > an extraordinary quantity of functionality that's contained in bar.c.
> > We put the latter's function declarations into bar.h and compile
> > bar.{c,h}¹ into bar.o.
> 
> Does bar.c contain a main{} definition?

Why would it?

> > Now we can compile foo.c (which #includes bar.h) over and over while
> > debugging it, all without ever recompiling bar.c. foo.c knows all it
> > needs to know about bar.c because of bar.h's declarations.
> 
> Can you now link bar.o into foo? I honestly don't know - I don't know
> how a linker will behave if fed two main{} functions ... ?

This isn't too hard. As I wrote, bar.c has functions, and bar.h has
declarations for those functions so that compiling foo.c can check
the calls of those functions without ever seeing bar.c (ie without
recompiling bar.c over and over).

> > I now have a suite.ly that typesets my Suite for flute and piano.
> > It \includes nine files: flute{I,II,III}.ily, piano{I,II,III}.ily
> > (the notes), and flute-part.ily, piano-part.ily and complete-score.ily,
> > (my \score templates). It also \includes {marks,dyns,fingers}.ily that
> > contain LP code for my preferred styles of markings, dynamics and fingering.
> > 
> > I have a file, suite.dep, which contains the information that suite.ly
> > depends on these files to produce three targets, {flute,piano,suite}.pdf
> > The same file might also indicate that I need just flute{I,II,III}.ily,
> > flute-part.ily and {marks,dyns,fingers}.ily for just a flute.pdf.
> > 
> > What do I write in a top-level theFlute.ly file to produce this
> > flute.pdf and how does it benefit from the suite.sep information?
> > How do I use this information profitably, in the way that bar.h did?
> > 
> > ¹ I'm abbreviating with shell's "brace expansion" notation.
> > 
> Now we get to the meat of the matter. You've put bar.c's
> *declarations* into bar.h. Does lilypond even have declarations? Also,
> it's perfectly normal practice to put *definitions* in .h files -
> static variables, macros, inline functions, etc etc.
> 
> I put most of my lilypond variable *definitions* into .ily files. Yup,
> .h files *tend* to contain declarations not definitions, but as I say,
> I don't think lilypond syntax has  declarations?
> 
> So yes, am I right in thinking you view .ily files as closer to .o
> files? With lilypond closer to a linker than a compiler?

No.

> At the end of the day, I see it as .h files can contain declarations,
> .ily files contain declarations. .h files are included, .ily files are
> included. Some languages (like lilypond) are monolithic and don't
> really have the concept of libraries. So I find it extremely easy to
> view .ly/.ily as being similar to .c/.h. Not the same, because
> lilypond is not gcc ... :-)
> 
> There's no one absolute view - you see things different to me, doesn't
> mean you (or me) is right.

Look¹, I'm not the one making this analogy. I'm trying to make any
sense of it, and why this "dependency file" is being built.

How do I use .ily files—almost all of them are definitions of
layouts, score structures, paper formats, variables' default values,
my abbreviations, and scheme code where it's wrapped in LP syntax.
They reside in a library directory that also has three subdirectories:
a collection of systematically named paper-margin files, a load of
boilerplate for exhaustively constructing MIDI file voice combinations,
and raw .scm files (like swing.scm).

One or two .ily files consist of source that's been factorised out of
the .ly file(s) that calls them. So, for example, there are festal
hymns that have words for the different seasons, so most of the
seasonal versions can be factorised out into an .ily file and then
inserted at the appropriate points in the main .ly file. There's
no saving in volume of compilation, only duplication.

I haven't used any equivalent of .o files in LP and don't know how
you would (which is why I'm asking). The nearest is with LaTeX
documents that construct PDFs from .tex files and small .pdf files,
so LaTeX (and sometimes an enclosing shell script) is acting as
the "link-loader". Even here, I don't save a lot of compilation.
For example, when I typeset a psalm for the choir, the (Anglican)
chants are automatically recompiled by LP so that they can be
transposed on the fly, to make the changes in chant work. (I often
repoint the psalm to the chants, too.)

¹ insert "at the thread" here.

Cheers,
David.