[26328] trunk/dports/gnustep/Etoile/Portfile

[Juan Manuel Palacios]

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