[114205] trunk/dports/_resources/port1.0/group/octave-1.0.tcl

[Ryan Schmidt]

On Dec 2, 2013, at 19:48, Michael Dickens wrote:
> On Mon, Dec 2, 2013, at 08:32 PM, Ryan Schmidt wrote:
>> On Dec 2, 2013, at 09:29, michaelld at macports.org wrote:
>>> +
>>> +	# work-around for case-insensitive file systems when the
>>> +	# extract directory name is the same as the octave module name
>>> +	# except for letter case; should always work no matter if the
>>> +	# file system is case-insensitive or case-sensitive.
>>> +
>>> +	move ${workpath}/${worksrcdir_name} ${workpath}/tmp-${worksrcdir_name}
>>> +	move ${workpath}/tmp-${worksrcdir_name} ${workpath}/${octave.module}
>> 
>> This really failed before? I’m surprised we don’t have a general fix for
>> this yet. I’d love to get this kind of fix into “proc move”. The whole
>> reason we have wrappers like “copy” and “move” is so that we can abstract
>> away things like this.
> 
> It actually failed on a buildbot of all places.  octave-nan's tarball is
> actually "NaN", but internally octave builds it as “nan"

Then that makes sense that it would fail on the buildbots, because the buildbots have case-sensitive filesystems. Not sure why our admins decided to set them up that way, but it does help to expose these kinds of problems, so that’s good.

> so I have to
> rename the tarball main directory to be what octave requires. The "move"
> from "NaN" to "nan" failed with a direct move, which means to me that
> the file system is case-insentive; the indirect move works.  I found it
> strange that "move" didn't handle this already,

This is what I meant. I was surprised that a case-only rename would fail, even on a case-insensitive filesystem; this can’t be the first time in 11 years that we’ve encountered this problem.

> but I mostly just wanted
> to fix it to work in those odd cases that users might encounter -- hence
> the quick fix instead of looking elsewhere. - MLD

I’ll do some testing and see if I can fix the `move` proc to handle this.