Re: Identify included files

[antlists]

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, 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.

And if they do compile, the output probably isn't much use ... :-)
> > 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?
> 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 ... ?
> 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.
>
> Cheers,
> David.
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?

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.

Cheers,
Wol