Thorsten Behrens wrote: > 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.
OK, so I misunderstood your intention for mentioning bjam. >> 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. Do you really believe that posting the "stupid ideas and questions" would have prevented that they crop up in the public discussion? :-) >> 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. Sounds good. :-) Any improvement would be welcome. Regards, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to "nospamfor...@gmx.de". I use it for the OOo lists and only rarely read other mails sent to it. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org For additional commands, e-mail: dev-h...@tools.openoffice.org
