Re: minutes of ESC call ...

Hi,

On Fri, Dec 09, 2016 at 11:45:56AM +0100, Jan Iversen wrote:
> Now we are getting very close to my x-mas wishlist.
>
> the current json files made by gbuildjson misses 2 things:
> - objective C++ (and some other language) files are not accounted for

Thats trivial to add and left as an excerise to the reader.

> - there are no dependency structure (as provided by running “make -d”)

There is: linked libs and linked static libs provide that for a 10000 feet
view. Of course its a simplification, because that is the whole point of the
gbuildtojson execise: Leaving out all the cornercases and shortcuts to have
something simplified that can be translated.

> - the gb_macros do not make the C++ program, but makes a simple echo with an identifier

That will likely explose on some platforms sooner rather than later due to
shell length limits. There is a reason we use var2file, the reasons for which
can be painfully exermined in the git log.

> - make is called with “make -d gbuildtojson | gbuildjson.exe

That will produce huge amounts of output and thus be very slow. Also it
reintroduces parsing GNU make output directly, which we are by now more than
aware to be fragile and prone to breaking. Better to cause the output of "make
gbuildtojson" to provide the needed info properly. The whole point of
gbuildtojson is to have some stable output and NOT be broken by (make-)version
specific behaviour.

> With that change the json files contains enough information to e.g. generate
> a new set of makefiles without macros.

So, generate makefiles from makefiles, because ... well, why? We have so far
successfully avoided the common autotools-style madness of creating generated
intermediate makefiles. Debugging those usually is a huge PITA.

Doing that is a kludge that was historically needed in the early 1990 as there
where a bazillion incompatible makes that where broken in many different ways.
Anyone having to deal with it hated it and will until the end of their life.
Those days are over and we can depend on GNU make being available (or portable)
everywhere. Thus generated makefiles should really really be avoided.

As of now, the only valid reason left for generated build files is the performance
of some backend tools (e.g. ninja) by having better caching/intermediate formats for
the (huge) dependency graph we produce. Ninja alone wont replace GNU make, so
we would still be using both, and we would need good reasons to justify the
inevitable "my ninja build does weird stuff, let me try to debug 200KLOC of
generated build instructions we threw at it"-fun it will yield.

Hint: Thus if we consider ninja as a backend for the build system with
performance as argument to use it, we would need some good hard cold number on
how much better ninja is at that.

However, this is shifting goalposts -- the original argument was about how hard
it is for a newcomer to get an initial build setup on Windows (still) and none
of this is helping with any of that (Steamlining LODE and documentation would,
however).

Best,

Bjoern