Re: scripts/build/scan-mf-deps: script to generate MF dependencies (issue 553700043 by address@hidden)

[jonas . hahnfeld]

On 2020/03/15 18:52:27, hanwenn wrote:
> > Not doing this at all.
> > In cases like this, I begin to question the very fundamental
> > assumptions. In this case: Do we really need to dynamically generate
the
> > dependencies if there's really no tool for it? My answer is "no"
after
> > seeing that the last change of 'include' statements was in 2013 (if
you
> > count a2f44bbf0e; otherwise maybe earlier). As such, how about just
> > making them static? See https://codereview.appspot.com/555440062 to
get
> > the idea.
> 
> FWIW, at some point the dependency generation was part of
> mf-to-table.py, which generated from the log file (using Python). I
> don't know why it was moved to be a make macro.
> 
> If we think we're not going to change the mf files, why not just check
> in the OTF files?
> 
> (tongue in cheek, but you get the idea).

IMHO you need to differentiate between changes to mf files (which I
think we should enable) and changes to the *structure* of the mf files.
The latter gets slightly more complicated with static dependencies. But
I don't expect many of them, much to the contrary of '#include's in C++.
_If_ dependencies become a problem in the future _and_ we're still using
make that point, we can of course revisit this issues.

On 2020/03/15 18:54:44, hanwenn wrote:
> On Sun, Mar 15, 2020 at 7:14 PM <mailto:address@hidden>
wrote:
> > > I very much agree with you, but out of the existing language
within
> > > our tree (Perl, Python, Shell, C++, Make), it is the least worst
> > > option. Make is too limited (see the mess that our makefiles are
> > > today), Shell has all the problems of Make. We can't use C++ in
the
> > > build system, and Perl is a godawful mess of line-noise.
> > >
> > > What do you suggest instead?
> >
> > Not doing this at all.
> > In cases like this, I begin to question the very fundamental
> > assumptions. In this case: Do we really need to dynamically generate
the
> 
> You didn't answer my question, but I realize it was imperfectly
stated.
> 
> My question is: what overall architecture do you propose for the build
system?

Using whatever makes sense from the GNU build system and reduce the
maintenance burden of the build system as much as possible. FWIW I fully
agree with David that the current shortcomings originate from what
LilyPond builds around Autoconf, GNU make et al. Using standard
solutions (aclocal, possibly Automake for dependencies of C++ files)
should enable us to reuse what others have already solved.

https://codereview.appspot.com/553700043/