GNU bug report logs - #15160
Is --disable-posix excluding too much?

Previous Next

Full log

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jan Schukat <shookie <at> email.de>
To: bug-guile <at> gnu.org
Subject: Is --disable-posix excluding too much?
Date: Thu, 22 Aug 2013 13:27:10 +0200

Hello, it's been a while since I wrote here. Took me a while to figure 
out how to best tackle the native type vector alignment thing properly. 
Ended up writing my own binary data formats and the smaller dynamically 
created ones get their own SCM_DEFINE c constructors. The compiled guile 
byte-vector format isn't too efficient anyway atm. Once true 
elf-binaries are generated I guess that is different, since they can be 
directly and natively embedded. When that comes along I might look into 
it again. It's always good to consolidate and unify code that can be, to 
reduce redundancy.

Anyway, new issues arise. Using a scripting language somewhat portably 
for non-performance critical management tasks is pretty normal right? 
One of the prime uses.
So, I'm walking directory trees now, and occasionally need to copy a 
file. But copy-file is not available when --disable-posix is configured. 
There are lot's of possible workarounds. Copying files in different 
languages is first semester programming assignments. The point is: a 
high level language shouldn't make you do this. File systems and paths 
are pretty much the same on all platforms guile runs on. And that's the 
the interface to the function: two paths. There is no reason to to not 
have that function everywhere.

Similarly for chdir. You can work around it, and the file tree walking 
functions make it mostly unnecessary. But I see no reason to leave it 
out. Any system guile runs on knows paths.

(oh, and --disable-posix is necessary to compile on/for windows/mingw, 
the cost of portability)

Regards

Jan Schukat

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.