setting variants on the fly
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. Randall Wood rhwood@mac.com http://shyramblings.blogspot.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."
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. Regards, -Markus -- Dipl. Inf. (FH) Markus Weissmann http://www.mweissmann.de/ http://www.macports.org/
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}]} {...}").
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/
Markus Weissmann wrote:
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.
Yes, the idea of multiple Portfiles per port was already brought up some time ago. This would also allow us to get rid of separate devel ports. At the moment they are rather useless for testing, because all dependencies would need to be on $foo-devel instead of the regular $foo. I the case of gtk2, I don't think it is a good idea to give the ports different names, because that will lead to problems with dependencies. For example, gtk2 and gtk2-quartz would be mutual exclusive and therefore you can only install one of them. It would be way better for specifying dependencies if both versions are available with the same name gtk2. Then the user could decide either to use quartz or not for dependents without changes needed on these port. With multiple Portfiles per port one could install the devel version for testing and link all dependencies which specify the regular port name with it. We would have better testing possibilities without the need for a unstable/stable tree separation. Regards, Rainer
I really would like to avoid having to fork every single port that depends on gtk2 or a dependency of gtk2. On 22 Nov 2007, at 08:10, Rainer Müller wrote:
Markus Weissmann wrote:
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.
Yes, the idea of multiple Portfiles per port was already brought up some time ago. This would also allow us to get rid of separate devel ports. At the moment they are rather useless for testing, because all dependencies would need to be on $foo-devel instead of the regular $foo.
I the case of gtk2, I don't think it is a good idea to give the ports different names, because that will lead to problems with dependencies. For example, gtk2 and gtk2-quartz would be mutual exclusive and therefore you can only install one of them. It would be way better for specifying dependencies if both versions are available with the same name gtk2. Then the user could decide either to use quartz or not for dependents without changes needed on these port.
With multiple Portfiles per port one could install the devel version for testing and link all dependencies which specify the regular port name with it. We would have better testing possibilities without the need for a unstable/stable tree separation.
Regards, Rainer _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Randall Wood rhwood@mac.com http://shyramblings.blogspot.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."
participants (4)
-
Markus Weissmann
-
Rainer Müller
-
Randall Wood
-
Ryan Schmidt