py-gtk unified

Aljaž Srebrnič g5pw at macports.org
Sat Dec 8 00:55:45 PST 2012


On 08/dic/2012, at 02:30, Ryan Schmidt <ryandesign at macports.org> wrote:

> On Dec 7, 2012, at 18:08, Aljaž Srebrnič wrote:
> 
>> On 08/dic/2012, at 00:32, Ryan Schmidt wrote:
>> 
>>> On Dec 7, 2012, at 09:23, Aljaž Srebrnič wrote:
>>> 
>>> 
>>> Bear in mind that we also have a gtk3 port already. Does pygtk support gtk3, or will it? If so, we should think about how we plan to handle that. (Separate py-gtk3 port? Subports? Variants?)
>> 
>> Fortunately, py-gtk won't support gtk3, there is another module for gtk3 named pyGObject [1].
>> 
>> [1] - http://stackoverflow.com/questions/5920049/learning-gui-programming-with-gtk2-or-gtk3
> 
> Ok, that's good to know.
> 
> I assume the reason why the py25 thru py27 ports are called gtk not gtk2 is that the module name is pygtk not pygtk2. There was a recent push to make sure the entire module name appears in the port name; under that theory, the port should be called py-pygtk.

Fine by me!

> 
> Whatever you change the name to, all ports depending on pygtk will have to have their dependencies updated and their revisions increased.
> 
> 
>> I'm attaching the actial diff, if anyone want to take a look before I commit.
>> <py-gtk2.patch>
> 
> You can leave out "python.default_version 27"; that is the default, when "24" is not in python.versions.
> 
> The dependencies should go inside the "if {${name} != ${subport}}" block, since the stub port does not actually depend on those other ports. The "use_configure yes" command also needs to go in that block, since its presence globally will cause the stub port to fail. The build and destroot changes could also go in that block since the stub port does not actually build or destroot anything, though having them set globally does not seem to cause problems, and there is precedent for keeping them global, since we habitually set master_sites and checksums outside that block, even though the stub port does not fetch any files.
> 
> The active_variants 1.1 portgroup should be used, with which you no longer need to put the require_active_variants in a pre-configure block manually.


Yes, I wrote that portfile before the active_variants update :)

Great! so I'll commit everything and edit+revbump the dependencies :)

--
Aljaž Srebrnič a.k.a g5pw
My public key:  http://bit.ly/g5pw_pubkey



More information about the macports-dev mailing list