[Libreoffice] patch for make to help in gbuild debugging
l.lunak at suse.cz
Wed Jun 29 08:56:42 PDT 2011
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.
l.lunak at suse.cz
More information about the LibreOffice