Re: [Libreoffice] patch for make to help in gbuild debugging

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.lunak@suse.cz