Re: Bug-make Digest, Vol 135, Issue 17

[Paul Smith]

On Mon, 2014-02-24 at 18:50 +0100, Bjoern Michaelsen wrote:
> Yes. But of course for any bigger C/C++ project, although a rather
> specific usecase, it makes up the majority of the source to parse.
> _If_ LibreOffice wouldnt already do some tricks, parsing the 13GB of
> generated dependencies would dwarf anything else in makes performance.
> And even with the tricks we do to reduce the deps to parse to some
> <350MB it still eats half of the time[1].

Yes, I definitely understand the issue and the desire for a solution.  I
actually spent some time considering it this weekend, and it was a fun
thought-exercise.  I imagine something like Python's auto-compilation
mode, generating a Makefile.mkc (or something) for "compiled makefile"
whenever it parsed a makefile.

The big issue is obviously detecting whether the compiled version is
appropriate and can be used, or the real makefile must be used instead.
I was trying to think about what the "inputs" to a makefile would be,
that would cause a pre-compiled version to be invalid.  Unfortunately,
there are a lot of them.  But I have to say it's an intruiging problem.


The best approach I think would be to provide a framework for compiled
makefiles, but solve the problem in stages: initially it would only
compile the very simplest makefiles.  If there were anything in the
makefile beyond the most basic syntax, it would simply not generate a
compiled output and always read in the real makefile.  Then over time,
more sophistication could be added to the compiler as we understood what
that might mean.

I would definitely want this to be totally invisible to the user and not
require any magic in makefiles (so no special include operator, etc.)
Basically it should either be so safe that there's no way to tell the
difference between using the compiled version or not (other than
performance), or it should not be generated at all.