setting variants on the fly

[Markus Weissmann]

On Wed, 2007-11-21 at 22:34 -0600, Ryan Schmidt wrote:
> On Nov 21, 2007, at 06:55, Markus Weissmann wrote:
> 
> > On Wed, 2007-11-21 at 06:17 -0500, Randall Wood wrote:
> >
> >> Is it possible?
> >>
> >> What I would like to do is be able to test either that a dependency
> >> was installed with a certain variant or that a file exists and then
> >> set a variant on the port being installed based on that information.
> >>
> >> Background:
> >> I am reworking the gtk2 port so that it can be installed without X11.
> >> What I want to be able to do is have "sudo port install gtk2" work
> >> correctly, installing gtk2 with the correct variants for the machine
> >> its being installed on without user intervention or complaint.
> >
> > I didn't try to hack a Portfile to do this, so no idea; if these are
> > common tests, we could include them in port(1) like with the platform
> > and architecture variants.
> >
> > Depending on a variant of a port to be installed will create a big  
> > mess
> > and is imho a bad idea:
> > If A requires C1, B requires C0 and C1 conflicts with C0 you're stuck.
> > I'd like to avoid having this kind of conflicts in the first place by
> > _not_ relying on variants. If it is crucial for a port to have  
> > something
> > installed in a "non-standard" way, either create a new port that takes
> > the non-standard options or try to make your requirements the defaults
> > for the dependencies.
> > A good example I just recently saw are the smlnj/smlnj-dev ports which
> > can both be installed simultaneously (different versions); ncurses and
> > ncursesw als come to my mind here.
> 
> I think Randall is going for something like this: gtk2 can use either  
> x11 or quartz libraries. He would like to be able to detect which of  
> these is already installed and select the correct variant of gtk2  
> automatically. And if neither x11 nor quartz is installed, then he  
> would like to use, let's say x11. I hope I've understood the request  
> correctly. If so, I think this can be done.  Something like:
> 
> if {quartz is available} {
> 	default_variants +quartz
> } else {
> 	default_variants +x11
> }
> 
> "quartz is available" could be implemented by looking whether a  
> specific file is present ("if {[file exists somefile]} {...}"). Or,  
> it could be implemented by checking if a particular port is installed  
> ("if {![catch {registry_active someport}]} {...}").
> 

ah, well - o.k.;
my first thought about this though still would be to do two ports:
gtk2-x11 and gtk2-quartz
I'd suspect that doing everything via variants will get very messy in
the long run, as version X may not work well for quartz while X+1 may be
a good choice -- and the other way round for x11.
The dilemma seems to be the same as with the python-modules:
"Most" stuff would work with both versions (2.4 and 2.5) but you
sometimes need to install both versions at the same time for
dependencies. Also some versions of some modules will drop support for
2.4 etc.

What would be _very_ cool to solve this problem would be something
Landon Fuller suggested: Some kind of inheritance for Portfiles.
Then we could do a gtk2 port with a description, version, hashes, etc.
and do a gtk2-quartz port which inherits from gtk2 but changes some
directories (for avoiding file conflicts with gtk2) and some options (to
enable quartz). If version X won't work for the inheriting port, it may
overwrite the version key and the checksums.

Well, that would be my "100%" solution. In order to make this work, we'd
need to do something similar as with the PortGroups, but rather read
other Portfiles than the group code.


Regards,

-Markus


PS: This would also make build runs and package generation _much_ easier
and more convenient as a user could get both versions of gtk2 as a
package.

-- 
Dipl. Inf. (FH) Markus Weissmann
http://www.mweissmann.de/
http://www.macports.org/