Re: [26328] trunk/dports/gnustep/Etoile/Portfile
Hi Yves! A couple of notes about this commit, if you don't mind: On Jun 19, 2007, at 5:17 PM, source_changes@macosforge.org wrote:
Revision 26328 Author yves@macports.org Date 2007-06-19 14:17:05 -0700 (Tue, 19 Jun 2007) Log Message
Add a devel variant to keep the unstable stuff out of the stable (Oh boy !)
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. Also:
Modified Paths
trunk/dports/gnustep/Etoile/Portfile Diff
Modified: trunk/dports/gnustep/Etoile/Portfile (26327 => 26328)
--- trunk/dports/gnustep/Etoile/Portfile 2007-06-19 20:56:13 UTC (rev 26327) +++ trunk/dports/gnustep/Etoile/Portfile 2007-06-19 21:17:05 UTC (rev 26328)
---snip---
+ system " + cd GNUstep/Local/Tools && + ln -s ../Applications/Calc.app/Calc && + cd ../Library/Headers && + rm -f AddressBook && + ln -s Addresses AddressBook + " }
You don't need a "system" call to do any of those things. Portfiles understand cd, we have an internal implementation for ln and one for delete
+variant devel { + build.args-delete etoile-extensions=no menuserver=yes jabber=no outerspace=no sketch=no + destroot.args-delete etoile-extensions=no menuserver=yes jabber=no outerspace=no sketch=no + build.args-append debug=yes corner=no + destroot.args-append debug=yes corner=no + + post-destroot { + cd ${destroot}${prefix} + xinstall -d GNUstep/System/Library/Etoile + xinstall -m 644 ${worksrcpath}/Services/Private/System/ SystemTaskList.plist \ + GNUstep/System/Library/Etoile + xinstall -d share/xsessions + xinstall -m 644 ${worksrcpath}/Services/Private/System/ etoile.desktop \ + share/xsessions + system " + echo \". ${prefix}/GNUstep/System/Library/Makefiles/ GNUstep.sh; \ + etoile_system\" > bin/etoile && + chmod 755 bin/etoile +
Maybe you can use xinstall here to tweak those permissions...? -jmpp
Le 07-06-19 à 18:16, Juan Manuel Palacios a écrit :
Hi Yves! A couple of notes about this commit, if you don't mind:
On Jun 19, 2007, at 5:17 PM, source_changes@macosforge.org wrote:
Revision 26328 Author yves@macports.org Date 2007-06-19 14:17:05 -0700 (Tue, 19 Jun 2007) Log Message
Add a devel variant to keep the unstable stuff out of the stable (Oh boy !)
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 ?
+ system " + cd GNUstep/Local/Tools && + ln -s ../Applications/Calc.app/Calc && + cd ../Library/Headers && + rm -f AddressBook && + ln -s Addresses AddressBook + " }
You don't need a "system" call to do any of those things. Portfiles understand cd, we have an internal implementation for ln and one for delete
Right. Now it's been a while but I always used "system" for symlinks because I ran into troubles with the tcl "file link". I don't remember exactly, but I think I got the build/destroot paths hardcoded in the symlinks. And I also had problems with the newer tcl extensions (copy, move) which I don't use either. I don't remember what happened exactly, but trying to use them was breaking my port, I don't think I filed a bug report on that, but I always use the tcl "file", except for symlinks of course. Any similar experiences about this ? yves
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" ;-)
+ system " + cd GNUstep/Local/Tools && + ln -s ../Applications/Calc.app/Calc && + cd ../Library/Headers && + rm -f AddressBook && + ln -s Addresses AddressBook + " }
You don't need a "system" call to do any of those things. Portfiles understand cd, we have an internal implementation for ln and one for delete
Right. Now it's been a while but I always used "system" for symlinks because I ran into troubles with the tcl "file link". I don't remember exactly, but I think I got the build/destroot paths hardcoded in the symlinks.
Tcl's file(n) command fails at creating symlinks to inexistent files (needed when you want symlink foo to point to file bar which will be in ${prefix} only after port activation), but Eridius implemented that functionality in our internal `ln' command. You should try it and file bug reports if you encounter any unexpected behavior with it, it should simply mimic ln(1).
And I also had problems with the newer tcl extensions (copy, move) which I don't use either. I don't remember what happened exactly, but trying to use them was breaking my port, I don't think I filed a bug report on that, but I always use the tcl "file", except for symlinks of course.
Any similar experiences about this ?
Not that I could say on my behalf, but if you do encounter problems/ unexpected behavior you should most definitely ask here and file tickets for them if bugs are confirmed. I'm sure Eridius would weigh in ;-) In any case, do go for the built-in commands and report your findings.
yves
Regards,... -jmpp
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
On Jun 20, 2007, at 10:29, Yves de Champlain wrote:
- 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).
This was suggested once, and implemented in a few ports, but I still don't see the advantage over the "normal" MacPorts variant naming, which would be, respectively, +utf8mac, +no_extra_encodings, and +cp932fix.
Le 07-06-21 à 16:51, Ryan Schmidt a écrit :
On Jun 20, 2007, at 10:29, Yves de Champlain wrote:
- 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).
This was suggested once, and implemented in a few ports, but I still don't see the advantage over the "normal" MacPorts variant naming, which would be, respectively, +utf8mac, +no_extra_encodings, and +cp932fix.
Well, if we could have a "normality" definition written in the new committers docs, that would just be many times better than having the most advantageous naming scheme anyway. yves
On Jun 20, 2007, at 11:29 AM, Yves de Champlain wrote:
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.
Totally for a variant naming guideline doc! But on that topic, read my recent message (cc'ing this list) to Maun Suang on the MacPorts guide, this type of document should most definitely be part of the "official" guide. Would you care to write a first draft and coordinate with Maun Suang its inclusion in the guide?
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.
"svn switch --relocate" to http://svn.macports.org/repository/ macports, MacOSForge uses http digest auth, no need for ssh/ssl.
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.
- 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).
Agreed too, replace all instances of - (as a word separation character, I'm assuming) with _, and + I just don't know what it's used for, but it definitely does not belong there! (use _ too?)
- a port's default variant (including no variant) should usually install the full features (except if it looks like madness)
This is a hotly debated topic: should ports be minimalists, deferring all non-default/basic extensions/functionality to variants? Or should they instead be all encompassing, providing everything the package has to offer out of the box? Somewhere in between, per maintainers' better judgement? I would support the latter, but I am more than aware that's a very grey area to be in, so I'll let others with stronger positions venture their opinions.
- variants should have a description
We should make this a must!
- platform variants are named "platform" instead of "variant" (many ports again)
Agreed too, common mistake that should be corrected.
- typical names : no_* x11 gtk2 aqua debug server ipv6
Aha, I like common names and people standardizing on them by sheer practice and/or jurisprudence (gotta love that word!), among other things that buys us the assurance that "variant cascading" will work seamlessly (port foo depending on port bar builds with variant baz, MacPorts will try to build bar with variant baz too if it provides it -- that fails if foo and bar name the variants differently, a total waste!). But I fail to understand what you tried to say with your sentence above...? In any case, common names should be documented in the guide and anywhere between encouraged and enforced ;-) A settlement on them also sorta implies an answer to my question above: should ports be minimalist or fully featured? If 'no_ipv6' becomes a standard variant, then they are minimalist; if instead 'ipv6' becomes the standard, then they are fully featured. The middle ground I'd like to advocate means having, for example, 'ipv6' as a standard and 'no_x11' as another one.
- 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).
Seconding Ryan in his reply to you, I favor simpler and shorter variant names. In all cases, variant descriptions should do a good job at explaining what they are about and what they imply with respect to the build and deps... that is, at explaining them ;-)
yves
Regards,... -jmpp
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. Regards, Glen
participants (4)
-
Glen Whitney
-
Juan Manuel Palacios
-
Ryan Schmidt
-
Yves de Champlain