There are a few reasons why this won't work :-)
First: What if I have assembler? python? perl?
Your example is limited to the C preprocessor.
Yes that i did tell there that it's limited to c already :) but bin dep, after all, is limited to lib dependencies and probably just .so files -- which means probably not python (as it's too dynamic to programmatically understand, where and which libs are used), not perl (as it doesnt have binaries). So i dont see my version being much worse than bin.
If you have an assembler, then everything depends on which one you have. If that's internal assembler of c, everything works fine ;) If that is some macro-assembler, then there is a bit different syntax from c, but other code is basically the same (parsing needed information out from assembler code is not too hard).
If that's python, then you cant anymore make it so simple -- there is nothing like #define in python, as it's dynamic. In python, you have several ways -- adding dependencies in classical way; adding a *.c file, which talks about dependancies or making some python script, which is able to tell on what it depends -- the last way has the same weakness with bin dep that it should be downloaded before.
About perl, i dont know enough to tell, how it could be used there, but anyway, as it is scripting language, i think that smth similar to py applies.
I think that there could be simple dependency builder for packages, which will be compiled, but not for dynamic languages. There is no simple way in dynamic languages for knowing, which libs will be used, even if you know the useflags or have them "built" into pyc files. As code deps are only my thought about repairing the biggest bottleneck in bin-dep - that you cant say anything about deps of a random combination of flags without rebuilding with excactly that combination -, i am not trying to make it usable in dynamic/scripting languages.
Second: You'll have to get this depend information applied by upstream
unless you want to patch every file ... and as upstream I'd laugh at
anyone proposing that
This is actually simple build. I just told about method, which would allow you to include dependancy metadata directly in c code. It could be "compiled" into current portage dependancy data as well.
Third: Since there is no easy way of generating this automatically
you'll have to replicate every bit of dependency information that is in
the ebuilds. That will be much work, you won't keep ebuilds synchronized
to the included dep info ...
Data in ebuilds should be generated from that data.
So in short, interesting concept, but I don't see how it can work and
how it is an improvement over what we have now. Please don't reinvent
the wheel ;-)
Yes, if it comes to wheels, i better try to invent a better wheel, not reinvent an old wheel ;)
PS. in my last example, i dont show how useflags are related to #defines. That's because i guess that it must be already described somewhere and have not to be in c code :) I hope it is so ;)
Patrick
--
Stand still, and let the rest of the universe move
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2-ecc0.1.6 (GNU/Linux)
iD8DBQBEIZTiqER3hOUoZM4RAkEtAJ913WnthMPjRZrUGQCgYnOw9Xcu7ACeO1Dh
VKWKYb6XcDuugBJSSBFMgc0=
=xD2e
-----END PGP SIGNATURE-----
--
tvali
From a programmer's point of view, the user is a peripheral that types when you issue a read request. -P. Williams
If you think your management doesn't know what it's doing or that your organisation turns out low-quality software crap that embarrasses you, then leave. -Ed Yourdon
We all agree on the necessity of compromise. We just can't agree on when it's necessary to compromise. -Larry Wall
[ http://www.softwarequotes.com/ ] - http://www.softwarequotes.com/ShowQuotes.asp?ID=544&Name=Borenstein,_Nathaniel_S. - http://www.softwarequotes.com/ShowQuotes.asp?ID=571&Name=Boehm,_Barry
