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