On Wed, 2006-03-22 at 19:40 +0200, tvali wrote: > I was thinking about it, too, and found something i do like maybe > more. It would be not binary, but code dependancy. This is limited to > specific languages, then, but after all, there may also be different > binary dependencies, too [for example, you may depend on fonts & > images from another package]. > > Ok, my thought is like that. Lets imagine a simple c file: > > #ifdef usepackagex > #include <packagex.h> > #endif > > As it is simple to see, this file could be used to calculate > non-binary dependency, inluding useflags. And there is a plus -- tool, > which just reads those #ifdef's and #includes, could easily > understand, which flags make up which dependancy, without building > package again and again with different useflags.
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. 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 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 ... 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 ;-) Patrick -- Stand still, and let the rest of the universe move
signature.asc
Description: This is a digitally signed message part
