On Wednesday 29 of June 2011, Thorsten Behrens wrote: > Lubos Lunak wrote: > > It is not another dmake, as I understand it, as you cannot simply nuke > > our dmake copy now and expect things to still work, whereas that would > > work with a gnumake copy as long as that one's extensions were kept to > > "unimportant" features like better debugging or performance. If the > > extensions are pushed upstream, the copy is synced to upstream, and the > > extensions are not relied upon, > > A few too many "ifs" to make me feel comfortable. You end up with > not being able to build without the in-tree gmake in no time - and > bingo, you're coding against a single implementation again.
How exactly is one supposed to end up not being able to build without the in-tree gmake if that gmake only has extensions for easier debugging and faster building? Correct me if I'm wrong, but I haven't seen proposals for any other kinds of extensions to the gmake copy. Besides, the only important "if" above is actually the one about not relying on the copy. The rest is irrelevant for those who simply would not use the copy for whatever reason. > > During the 3.x times KDE used a home-brewn automake+make replacement > > (called unsermake ... don't ask) that supported a subset of automake+make > > functionality and while people could still build using automake+make if > > they wished so for whatever strange reason, using unsermake was just so > > much better. > > I fail to see the point you're trying to make - the proposal at hand > looks more like a superset, not a subset. ;) A superset of what? Just because this thread started with a patch adding some non-crucial functionality doesn't mean there has to be any superset as far as the actual building goes, and if there was any such proposal I must have missed it. And it may very well be a subset if it's found out that some stone-age make feature like built-in rules are making it slower and we just stop using it and turn the support for it off in our copy. The point I was trying to make was that it's doable. Sure, LO has a lot of OOo heritage of doing retarded things just because of the fun of it all over the place, but that doesn't mean we have the keep the tradition, do we? If we can without trouble implement the rule of reviewing patches before backporting, surely we can as well implement the rule of not actually relying on our own build tool copy again. -- Lubos Lunak l.lu...@suse.cz _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice