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.
> 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. ;) Cheers, -- Thorsten
pgptJrXjWfLXw.pgp
Description: PGP signature
_______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
