At 20:45 Uhr -0500 02.02.2002, Kyle Moffett wrote:
>  On Saturday, February 2, 2002, at 08:25 , Randal L. Schwartz wrote:
>
>>Kyle> $hash->{variant}{xwin} = the contents of the variant foo
>>Kyle> $hash->{variant}{xwin}{cppflags} = the CPPFlags used when compiling
>>Kyle> with xwindows support
>>
>>I hope you realize you can't use both of these at the same time.
>>If $hash->{variant}{xwin}{cppflags} is active, then $hash->{variant}{xwin}
>>has to be a hashref, stringifying as HASH(0xNNNNN).
>>
>>Common error, want to make sure you're not making same.
>
>I was not referring to those as strings, but I was intending for 
>$hash->{variant}{xwin} to be a hashref.  The current (old) package 
>hash looks like:
>
>{
>       cppflags => "-I/usr/X11R6/include",
>       ldflags => "-L/usr/X11R6/lib",
>       [...]
>}
>
>I was thinking that we could store variants in a form like this
>
>{
>       cppflags => "-I/usr/X11R6/include",
>       ldflags => "-L/usr/X11R6/lib",
>       variants => [ "foo", "bar", "nox" ],
>       variant => {
>               foo => {
>                       cppflags => "-I/sw/include/foo/include",
>                       ldflags => "-L/sw/lib/foo/lib",
>                       [...]
>               },
>               bar => {
>                       cppflags => "-I/sw/include/bar/include",
>                       ldflags => "-L/sw/lib/bar/lib",
>                       [...]
>               },
>               nox => {
>                       cppflags => "",
>                       ldflags => "",
>                       [...]
>               },
>       },
>       [...]
>}
>
>Though ideally, xwindows support would be added (like variant xwin) 
>instead of subtracted (like variant nox).


I don't see why we would want to do this, and what advantage it would 
give us, but I will be glad to hear your points.

What I thought we should do is that when we read in a single .xinfo 
file with all its variants, the "XML reader" module (as opposed to 
the "classic info reader" module) would generate multiple packages 
from this single template.

So if you have a package "foo" with variants x11, gnome and ssl, 
where gnome implies x11, it would generate "full" package entries for 
foobar, foobar-ssl, foobar-x11, foobar-gnome and foobar-gnome-ssl in 
the internal database of packages. To the rest of Fink, there would 
be almost no difference.

"Almost" because we would still add some additional information. But 
for most purposes, there would be no difference, e.g. the reader 
module would determine once how the CPPFLAGS for the given variant 
should look like etc. The rest of Fink has almost no need to know 
about this at all. It would also add automatically conflicts/depends 
relations between all those variants.


I said "almost" -> we still want to allow the user to be able to 
specify in a comfortable fashion which variant to use. Etc.


Having now written down this, I see some things I am not completly 
fond of in this scheme, too. Anyway, this should give you some stuff 
to think on, too, so that we may converge in the end to "best" 
solution :)


Anyway, I am heading of to bed now, it is waaay to late already :)


Max
-- 
-----------------------------------------------
Max Horn
Software Developer

email: <mailto:[EMAIL PROTECTED]>
phone: (+49) 6151-494890

_______________________________________________
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel

Reply via email to