Mathias Bauer wrote: > So if you could explain how bjam (or any other make system that > someone wants to suggest here) solves our problems or why the > problems that require bjam to be resolved are even bigger than > those we try to fix, we might be able to get somewhere. > I did that, if you could check my initial posting. Bjoern said he profiled gnu make with large enough synthetic rule sets, point is settled for the while, I'd say.
> You can find most of our findings, discussions etc. in the wiki (I have > posted the link several times) or in Björn's and my blogs. > Nothing we're discussing here except Bjoern's initial blog from Friday, sorry Mathias. This is not to criticize anybody, just pointing out that, when such things are announced after-the-fact, many of the stupid ideas & questions that have probably been resolved internally before, will crop up in the public discussion again. > Björn also will post some more data about GNU make investigations > soon. They never were planned to be "internal findings", but > posting them without prior explanation wouldn't have made sense > and even now they don't add anything to the discussion we wanted > to start. The topic is not "can GNU make do that", but "do we have > the right goals" and "GNU make can reach the goals, which other > tools can do it also or perhaps even better". > Understood. I pretty much agree with the goals, assume you did your due diligence on verifying that gnu make does not trip over on the full input set (that was my point of cautioning you, with the bjam story), and am now trying to explore ideas on how to make the actual makefiles appealing - the current state is not convincing, just plainly because they're not substantially different from the ideal dmake makefile in the existing system - and with their redundancies, will suffer the same bitrot as the old system. Cheers, -- Thorsten
pgpzK3a9qWqvu.pgp
Description: PGP signature
