Portfile guidelines (was 
gwhitney at macports.org
Mon Jun 25 11:02:01 PDT 2007
On Fri, 22 Jun 2007, Juan Manuel Palacios wrote:
>> 2- to include some variants naming guidelines like
>> - devel is not a variant name, it is reserved for different ports that
>> install different version of a single package (quite a few ports have a
>> devel variant actually)
> Agreed on the first count. On the second one, maintainers of those
> ports should be ping'd to correct that, 'devel' should be reserved for a
> foo-devel port.
I have followed the discussion on this point, and the consensus is very
clear: a port that installs, say, the Subversion head of a package foo
rather than a stable release of foo should be a separate port called
foo-devel rather than a "foo +devel" variant of the port foo. In light
of this, though, could somebody offer advice how to handle the following
situation that comes up in my effort to try to get Macports to build
GnuCash with the quartz version of gtk:
Currently, for this to work, some of the low-level libraries (e.g. Cairo,
gdk) must be bult from HEAD rather than a stable release version. However,
there are then many levels of intermediate libraries (e.g. libglade, etc.)
which are built on top of this, who don't really care about which version
of Cairo or gdk was installed, they will compile with either the stable
release or these head versions; and they'll run with either under X11, and
run with the head versions under Quartz (although the X11 vs. Quartz
choice has to be made at the time the low-level libraries are built, it
can't be changed/selected at the time the intermediate libraries are built
on top of them). Finally, gnucash itself doesn't care about any of this
stuff, it builds and links with any sufficiently up-to-date versions of
the intermediate libraries.
Now, the quartz/x11 choice is (in most cases already before I got there)
handled by variants on the low-level libraries, which works nicely: the
higher layers have their dependencies satisfied and they build and link
and if you selected +quartz below you get apps that open up right in
quartz, otherwise X11 has to be running.
However, I understand with the HEAD version stuff the proper procedure is
to make other ports, e.g. cairo-devel. But now how do I handle the
higher layers? Do I have to duplicate all the ports that depend on cairo
to have a version that differs only in that it depends on cairo-devel?
But duplicating information creates maintenance headaches, and
libglade-devel ought to be a port of libglade which is based on libglade
development code, not a port which uses stable release code of libglade
but links with devel versions of underlying libraries. I could call it
libglade-devellibs, but there is still the code duplication issue.
Moreover the problem is worse at the gnucash level: there is already a
gnucash-devel port tracking the 2.1 series and a gnucash port tracking
2.0. Either can compile with the quartz low-level libraries, so do I
need a gnucash-devel-devellibs (and a gnucash-devellibs)?
So you can see why prior to this thread I was planning to use +devel
variants on the low-level libraries in parallel with the +quartz variants,
then all these dependencies would be satisfied naturally.
Given that by MacPorts current policy the head version of Cairo has to be
a separate cairo-devel port, any suggestions on how to handle the layers
built on top? As far as I have seen, there's no way to have an either/or
dependency. Is there a way to make a dummy port whose only purpose is to
ensure that either cairo or cairo-devel had been installed? If so, what
should it be called? (cairo-ensure?) And what should/will happen when you
"port install gnucash" and it recursively gets to installing cairo-ensure?
(i.e. can it be engineered to build cairo or cairo-devel? And if so, how
would that choice be controlled? Would it be legitimate for cairo-ensure
to have a +devel variant which would build cairo-devel to
satisfy itself, with the default to build cairo? )
Thanks for any policy guidelines and/or implementation suggestions for
handling this situation.
More information about the macports-dev