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. PS. i dont mean X by packagex, but rather a random pack. I write here as if #define always includes useflag name - i may be wrong, but it doesnt make a huge difference. Sure, there are #ifdef's in code, which should not read, so we must have an array for legal useflags - but this is also not important in my explanation.

Lets add some custom comment syntax (line numbers are given for explanation):

1. #ifdef usepackagex
2. /* Portage: packagex.h = abc-def/packagex => 1.0.2 */
3. /* Portage: use fonts/customfontpackage */
4. #include <packagex.h>
5. #endif

Now, what a parser does:

Start parse: setup empty array UseFlags = []

Line 1: #ifdef usepackagex
Add useflag name into useflags array:
UseFlags = ['usepackagex']
Line 2: /* Portage: packagex.h = abc-def/packagex => 1.0.2 */
This line maybe outside of any #ifdef's as well, but in our small application there is no external conf.c file ;)
Dictionary 'Links' will contain a notice that whenever packagex is included, it must be at least version 1.0.2 of package abc-def/packagex.
Line 3: /* Portage: use fonts/customfontpackage */
Dependancy on fonts/customfontpackage, therefore add to dependancies:
[['usepackagex'], 'fonts/customfontpackage']
Line 4: #include <packagex.h>
Dependancy on fonts/customfontpackage, therefore add to dependancies:
[['usepackagex'], 'abc-def/packagex => 1.0.2']
Line 5: #endif
Remove 'usepackagex' from useflags:
UseFlags = []

2006/3/22, Gustavo Sverzut Barbieri <[EMAIL PROTECTED]>:
On 3/20/06, tvali <[EMAIL PROTECTED]> wrote:
> 2006/3/20, Gustavo Sverzut Barbieri <[EMAIL PROTECTED]>:
> >
> > I do think you're overcomplicating things where you shouldn't.
> >
> > Declaring stuff manually will always break, and to ensure a safe
> > system, it's better to use compiler information.
>
> In all cases, dependancy should be based on interfaces, not code.
>
> All packages may:
> * Provide an interface
> * Use an interface
>
> Depending on useflags, OS and other compile options, it differs, which
> interfaces are provided and used.
>
> This is, abstractly, what portage does with interfaces.
>
> If portage uses some interface, it may need it's header files when
> building. It may also need another lib for static build. This means
> that binary check is not possible in all cases.
>
> Now, the problem is:
> * How to get an information about a package, which specifies exactly,
> which interface is needed. How to get it before building in case when
> this interface is needed to be emerged before compilation [before
> linking everything together, at least]. Which is a form of this
> information and what could be read out from that?
> * How to get information about which interfaces are provided by which
> packages *not yet emerged* -- by their current use flags(?). This
> means that it must be possible to know, which interfaces are provided
> by packages, without first building it -- and the form given by binary
> check must be the same as the form of descriptor used by this package
> check.
>
> So, how to get correct provider together with correct client?

Ok, I agree with you that this would be the perfect solution, but it
would demand too much effort to have this right.

I'm not proposing the final-perfect solution, just something better
than we have now. It would not cover every case, but would cover most
cases in a satisfactory way.


--
Gustavo Sverzut Barbieri
--------------------------------------
Jabber: [EMAIL PROTECTED]
   MSN: [EMAIL PROTECTED]
  ICQ#: 17249123
Skype: gsbarbieri
Mobile: +55 (81) 9927 0010
Phone:  +1 (347) 624 6296; [EMAIL PROTECTED]
   GPG: 0xB640E1A2 @ wwwkeys.pgp.net

--
gentoo-portage-dev@gentoo.org mailing list




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

Reply via email to