Portfile guidelines (was 
Yves de Champlain
yves at macports.org
Wed Jun 20 08:29:31 PDT 2007
Le 07-06-20 à 10:38, Juan Manuel Palacios a écrit :
> On Jun 19, 2007, at 7:00 PM, Yves de Champlain wrote:
>>> I couldn't make it out from your edits, so I'm not sure if the
>>> devel variant changes the port version number (a big NO-NO!!),
>>> but even if it doesn't everybody is much better off if you turn
>>> it (the devel variant) into a different port. Even if for
>>> consistency with other -devel ports.
>> Um, the fact here is that Etoile is many things (apps, frameworks,
>> theme engine ...). The devel variant just builds the whole
>> package and enables debugging while the novariant builds a reduced
>> set, targetting only the stable parts of the exact same source
>> tree. I won't argue about the consistency, but making two
>> different ports means that they will overlap with one another and
>> there is no mechanism in MP about this (except failing on activate).
>> What do you think ?
> I see... it did not seem to me like you were building a different
> version of the package, indeed, but your commit log did raise my
> eyebrows ;-) So if you're still working with the same source tree,
> maybe we could think up some different names for your variants?
> (Yes, in this case two different ports would not be the best
> approach, most definitely). I was thinking, if possible with your
> source tree, maybe you could split the full build and the debug
> functionality in two different logical blocks? Thus your port would
> have something like +full (or whatever other name is more
> appropriate for the full build) and +debug (which would enable
> building with debug symbols). Based on that, full + debug == your
> current 'devel' variant. That's just a suggestion that I'm hoping
> is not too outlandish with respect to Etoile, of which I know
> nothing about.
> I know we don't have a written on stone mandate for variant
> naming, and maybe we should actually have it, but for the time
> being I believe working with the jurisprudence set by previously
> accepted practices is a fairly reasonable thing to do. In this
> case, said jurisprudence suggests a +devel variant is something to
> avoid in favor of *-devel ports. I know this is not your particular
> case with Etoile (you're not changing version number), as you made
> clear, but then I'd say "lets avoid the confusion too" ;-)
This seems like a very good solution to me. I am definitly in favor
of coherent naming schemes and guidelines.
While being there, an update to the newmaintainer wiki page would be
1- because it suggests that svn commit access needs ssh which turns
out to be quite unstable.
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)
- don't use "+" or "-" in variants names because they are "reserved
words" of the variant mechanism (many ports still use "-" which just
does not work).
- a port's default variant (including no variant) should usually
install the full features (except if it looks like madness)
- variants should have a description
- platform variants are named "platform" instead of "variant" (many
- typical names : no_* x11 gtk2 aqua debug server ipv6
- more obscure names should either have a good description or a
clearer name like with_* / without_* / enable_* / disable_* to at
least give a clue if we are triggering a dependency or an inner
mechanism. A good example : disable_utf8mac,
disable_extra_encodings, enable_cp932fix (libiconv).
More information about the macports-dev