Re: [gentoo-portage-dev] DB and binary dependency

[tvali]

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 <barbieri@×××××.com>:
>
> On 3/20/06, tvali <qtvali@×××××.com> wrote:
> > 2006/3/20, Gustavo Sverzut Barbieri <barbieri@×××××.com>:
> > >
> > > 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: barbieri@×××××.com
>    MSN: barbieri@×××××.com
>   ICQ#: 17249123
> Skype: gsbarbieri
> Mobile: [phone]
> Phone:  [phone]@××××××××××××××.com
>    GPG: 0xB640E1A2 @ wwwkeys.pgp.net
>
> --
> gentoo-portage-dev@g.o 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