1 |
I was thinking about it, too, and found something i do like maybe more. It |
2 |
would be not binary, but code dependancy. This is limited to specific |
3 |
languages, then, but after all, there may also be different binary |
4 |
dependencies, too [for example, you may depend on fonts & images from |
5 |
another package]. |
6 |
|
7 |
Ok, my thought is like that. Lets imagine a simple c file: |
8 |
|
9 |
#ifdef usepackagex |
10 |
#include <packagex.h> |
11 |
#endif |
12 |
|
13 |
As it is simple to see, this file could be used to calculate non-binary |
14 |
dependency, inluding useflags. And there is a plus -- tool, which just reads |
15 |
those #ifdef's and #includes, could easily understand, which flags make up |
16 |
which dependancy, without building package again and again with different |
17 |
useflags. PS. i dont mean X by packagex, but rather a random pack. I write |
18 |
here as if #define always includes useflag name - i may be wrong, but it |
19 |
doesnt make a huge difference. Sure, there are #ifdef's in code, which |
20 |
should not read, so we must have an array for legal useflags - but this is |
21 |
also not important in my explanation. |
22 |
|
23 |
Lets add some custom comment syntax (line numbers are given for |
24 |
explanation): |
25 |
|
26 |
1. #ifdef usepackagex |
27 |
2. /* Portage: packagex.h = abc-def/packagex => 1.0.2 */ |
28 |
3. /* Portage: use fonts/customfontpackage */ |
29 |
4. #include <packagex.h> |
30 |
5. #endif |
31 |
|
32 |
Now, what a parser does: |
33 |
|
34 |
Start parse: setup empty array UseFlags = [] |
35 |
|
36 |
Line 1: #ifdef usepackagex |
37 |
Add useflag name into useflags array: |
38 |
UseFlags = ['usepackagex'] |
39 |
Line 2: /* Portage: packagex.h = abc-def/packagex => 1.0.2 */ |
40 |
This line maybe outside of any #ifdef's as well, but in our small |
41 |
application there is no external conf.c file ;) |
42 |
Dictionary 'Links' will contain a notice that whenever packagex is included, |
43 |
it must be at least version 1.0.2 of package abc-def/packagex. |
44 |
Line 3: /* Portage: use fonts/customfontpackage */ |
45 |
Dependancy on fonts/customfontpackage, therefore add to dependancies: |
46 |
[['usepackagex'], 'fonts/customfontpackage'] |
47 |
Line 4: #include <packagex.h> |
48 |
Dependancy on fonts/customfontpackage, therefore add to dependancies: |
49 |
[['usepackagex'], 'abc-def/packagex => 1.0.2'] |
50 |
Line 5: #endif |
51 |
Remove 'usepackagex' from useflags: |
52 |
UseFlags = [] |
53 |
|
54 |
2006/3/22, Gustavo Sverzut Barbieri <barbieri@×××××.com>: |
55 |
> |
56 |
> On 3/20/06, tvali <qtvali@×××××.com> wrote: |
57 |
> > 2006/3/20, Gustavo Sverzut Barbieri <barbieri@×××××.com>: |
58 |
> > > |
59 |
> > > I do think you're overcomplicating things where you shouldn't. |
60 |
> > > |
61 |
> > > Declaring stuff manually will always break, and to ensure a safe |
62 |
> > > system, it's better to use compiler information. |
63 |
> > |
64 |
> > In all cases, dependancy should be based on interfaces, not code. |
65 |
> > |
66 |
> > All packages may: |
67 |
> > * Provide an interface |
68 |
> > * Use an interface |
69 |
> > |
70 |
> > Depending on useflags, OS and other compile options, it differs, which |
71 |
> > interfaces are provided and used. |
72 |
> > |
73 |
> > This is, abstractly, what portage does with interfaces. |
74 |
> > |
75 |
> > If portage uses some interface, it may need it's header files when |
76 |
> > building. It may also need another lib for static build. This means |
77 |
> > that binary check is not possible in all cases. |
78 |
> > |
79 |
> > Now, the problem is: |
80 |
> > * How to get an information about a package, which specifies exactly, |
81 |
> > which interface is needed. How to get it before building in case when |
82 |
> > this interface is needed to be emerged before compilation [before |
83 |
> > linking everything together, at least]. Which is a form of this |
84 |
> > information and what could be read out from that? |
85 |
> > * How to get information about which interfaces are provided by which |
86 |
> > packages *not yet emerged* -- by their current use flags(?). This |
87 |
> > means that it must be possible to know, which interfaces are provided |
88 |
> > by packages, without first building it -- and the form given by binary |
89 |
> > check must be the same as the form of descriptor used by this package |
90 |
> > check. |
91 |
> > |
92 |
> > So, how to get correct provider together with correct client? |
93 |
> |
94 |
> Ok, I agree with you that this would be the perfect solution, but it |
95 |
> would demand too much effort to have this right. |
96 |
> |
97 |
> I'm not proposing the final-perfect solution, just something better |
98 |
> than we have now. It would not cover every case, but would cover most |
99 |
> cases in a satisfactory way. |
100 |
> |
101 |
> |
102 |
> -- |
103 |
> Gustavo Sverzut Barbieri |
104 |
> -------------------------------------- |
105 |
> Jabber: barbieri@×××××.com |
106 |
> MSN: barbieri@×××××.com |
107 |
> ICQ#: 17249123 |
108 |
> Skype: gsbarbieri |
109 |
> Mobile: +55 (81) 9927 0010 |
110 |
> Phone: +1 (347) 624 6296; 08122692@××××××××××××××.com |
111 |
> GPG: 0xB640E1A2 @ wwwkeys.pgp.net |
112 |
> |
113 |
> -- |
114 |
> gentoo-portage-dev@g.o mailing list |
115 |
> |
116 |
> |
117 |
|
118 |
|
119 |
-- |
120 |
tvali |
121 |
|
122 |
>From a programmer's point of view, the user is a peripheral that types when |
123 |
you issue a read request. -P. Williams |
124 |
|
125 |
If you think your management doesn't know what it's doing or that your |
126 |
organisation turns out low-quality software crap that embarrasses you, then |
127 |
leave. -Ed Yourdon |
128 |
|
129 |
We all agree on the necessity of compromise. We just can't agree on when |
130 |
it's necessary to compromise. -Larry Wall |
131 |
|
132 |
[ http://www.softwarequotes.com/ ] - |
133 |
http://www.softwarequotes.com/ShowQuotes.asp?ID=544&Name=Borenstein,_Nathaniel_S. |
134 |
- http://www.softwarequotes.com/ShowQuotes.asp?ID=571&Name=Boehm,_Barry |