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
Attachment:
pgpCmltkc611r.pgp
Description: PGP signature