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:
>>
>>> I propose to unify everything under the name py2[5-7]-gtk2 since we have
>>> the gtk2 port. We could mark the -gtk ports replaced_by its -gtk2
>>> counterparts. What do you think?
>>
>> 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.
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.
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
