On 08/dic/2012, at 02:30, Ryan Schmidt <[email protected]> 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

_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev

Reply via email to