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
nice :
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
ports again)
- 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).
yves
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
