Can't say anything about the C++ stuff, but the second user of shared libraries
is going to be lxdialog - hopefully this evening already, in my patches (it
already works, I'm only cleaning out few details now; lxdialog + mconf is also
user of both these extensions).
I don't think the complexity increase is so dramatical - theoretically, it
almost shouldn't affect the normal build, except one scan for .so extensions,
right? Maybe we could do with some less generic way here, like specifying .so
dependencies in a special variable? On the other side, moving .so processing to
the user entirely would already mean some amount of duplication now (given that
my lxdialog + mconf patch will be accepted ;-).
I personally think that the -linkobjs variable adds practically zero overhead,
while having potential to be generically useful in other places than lxdialog.
About host-cshlib-extra, if we aren't going to entirely remove .so processing,
I believe that it should go in as well, since eventual move of .so processing
to separate set of rules will probably mostly affect one step higher level of
rules / variables than this, and this variable is going to be useful in the
both cases.
Kind regards,
-- Petr "Pasky" Baudis . This host is a black hole at HTTP wavelengths. GETs go in, and nothing comes out, not even Hawking radiation. -- Graaagh the Mighty on rec.games.roguelike.angband . Public PGP key && geekcode && homepage: http://pasky.ji.cz/~pasky/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/