Re: function.c, unlink, copy

[David Boyce]

At 04:34 PM 9/28/2005, Torsten Mohr wrote:
> thanks for your answer, but that's not really what i want to
> say, maybe i was unclear.  I wanted to state that a Makefile
> that gets copied or installed to other PCs, you can't really
> rely on the environment variables to be set properly.  These
> conditional parts are not really nice.
> Why not have an internal variable set at compile time
> of "make"?  Like perl's variables in the module "Config".

I previously sent in a one-line patch which adds this (it's a 
one-liner because the value is already calculated for build purposes; 
it's just a matter of "promoting" it into the binary as a make 
variable). But the patch wasn't accepted, I believe for two reasons: 
(1) it's late in the home stretch of releasing 3.81 and (b) the 
official position is that no more functions go into GNU make pending 
the integration of Guile as an internal scripting language. New 
functions are suggested frequently and the answer is always "wait 
till Guile is linked in, at which point it will be easy". Which is a 
fine position, IMHO, except that Guile integration is a long way off.

> But the other thing that i really want to ask for:
> Wouldn't it be useful to have a function like "unlink"
> or "copy" added, i use them very often, shouldn't that
> help others too?  Then you would have these functions
> available on ALL platforms.

That makes sense at first glance, at least for unlink. But when you 
try to carry it to more constructive activities things quickly get 
complicated. Should a copy() function preserve time stamps a la cp -p 
or not? What about permissions? Should it behave the same on all 
platforms or like cp on Unix and like "copy" on Windows? What about 
resource forks on Mac OSX? What about recursive copies of directories? Etc.

So, though I also feel some frustration about the Guile roadblock, I 
don't think internalizing OS semantics is the way. Having a built-in 
platform variable would be nice though.

Perhaps an platform-independent implementation of rm/cp/mv/etc 
semantics could become part of the GMSL which might be a nice compromise.

-David Boyce