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

[tvali]

Supposing that you have those
#provide header <header.h>
lines in all your packages, which provide something (and, of course, only in
those places in code, where they actually do so that useflags might be
correct), there may be some command of dep builder, which just uses those
providings, putting them together with it's
#use header <header.h>

This is not maybe common case, when interfaces and atoms have to be used.

File with
#provide header <header.h>
lines could also be autobuilt -- if you have copied all common *.h files
into some dir, which you are going to just put into /lib, then you're done.

That's somewhat a question, how it should be differenciated if .so is needed
or just headers and code, but there are several more or less simple
solutions. In all cases, data about which .so file is needed should be
contained in .h file, not in a package, which is going to use it -- i think
so.

2006/3/22, tvali <qtvali@×××××.com>:
>
> As an addition to code deps discussion.
>
> I didnt understand exactly, why bin deps were supposed to be better than
> what we have now, as i am not yet exactly sure what we have :)
>
> Anyway, i see one basic plus of code deps. It's that you may have huge
> number of codelines, all containing #defines and #ifdefs. You may know that
> whenever it uses <?.h> header, it needs library ? -- but when you need <?.h>
> may be somewhat complex case. There may be, for example, 40 different .h
> files of your own, which include ?.h file -- and each of them may be
> included only if corresponding useflag is set. In such case, it's easier to
> describe, which package you need when <?.h> is used than to write all those
> if's twise in code and some other place, which make sure if you need that ?
> pack or not.
>
> I havent done such thing in reality, so i dont know, how big problem it is
> for a programmer (how much you have that situation i described in real
> life), but i guess that this is the problem what binary deps were supposed
> to solve.
>
> --
> 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
>



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