#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 <[EMAIL PROTECTED]>:
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
