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 ;-)

Stand still, and let the rest of the universe move

Attachment: signature.asc
Description: This is a digitally signed message part

Reply via email to