Re: Identify included files

[Wols Lists]

On 22/05/20 02:08, David Wright wrote:
> 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:

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

A variable declaration. You know - EXACTLY THE SAME as C programmers
often stick in .h files ...
> 
>> And if they do compile, the output probably isn't much use ... :-)
> 

>>
>> Does bar.c contain a main{} definition?
> 
> Why would it?

Why WOULDN'T it?

You said that bar.c contained a load of functionality that you wanted in
foo.c. How am I supposed to know whether bar.c is a program or a library?
> 
>>> 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 don't have a clue. Your workflow sounds completely weird and totally
incomprehensible to me. You know what? I don't give a monkeys - your
world view is what you choose to see. You see things different to me!
>>>
>>> ¹ 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.

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

I didn't make it either! I just happen to totally agree with it.
> 
> 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.

WHICH IS EXACTLY A REASON FOR .h FILES! Removing duplication is a good
way of removing errors (or making them easier to fix :-)
> 
> 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.)
> 
Well, the way *I* see *ME* using .o files in lilypond is exactly the way
I use make in lilypond - they are virtual targets that don't have a
physical existence. The fact that they happen to have the same name as a
physical file that does exist is neither here nor there. If a .ily has a
bunch of include statements, I have a virtual target (a .o if you like)
with the parent name that depends on the sub-names.

In other words, I am using make to manage my .ily files in EXACTLY THE
SAME way I would use make to manage my .h files in a C project. It
sounds to me like you don't work that way. What on earth are your .dep
files? What are your .sep files (or was that a typo? :-) Your workflow
doesn't make sense to me!

I know I'm weird - I "don't do" visual, and guis, and all that sort of
stuff. I'm much happier with text. I know that makes me a "unix
greybeard" - it's only about 10% of the population that feels that way,
but I REALLY don't understand why most people are much happier with
pictures.

I know you say you want to understand what we're thinking, but you're
coming across as though you believe your POV is the "right" one. From
*my* POV yours doesn't make sense! Forget C, forget lilypond, look at
the broader picture, look at make, and as far as I'm concerned, .ily
files fit in my make worldview exactly the same way as C .h files fit
in. For me that analogy is perfect.

Cheers,
Wol