GNU bug report logs -
#15160
Is --disable-posix excluding too much?
Previous Next
Reported by: Jan Schukat <shookie <at> email.de>
Date: Thu, 22 Aug 2013 11:28:02 UTC
Severity: normal
Done: Andy Wingo <wingo <at> pobox.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
Your bug report
#15160: Is --disable-posix excluding too much?
which was filed against the guile package, has been closed.
The explanation is attached below, along with your original report.
If you require more details, please reply to 15160 <at> debbugs.gnu.org.
--
15160: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=15160
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
Hi!
--disable-posix is intended to be a size reduction thing, not
necessarily a portability hack. Guile should build on MinGW with POSIX
enabled; if it doesn't that's a different bug :) When POSIX support is
enabled we should simply compile out features that aren't detected on
the platform. For that reason it doesn't make sense to take more things
out from under --disable-posix.
Regards,
Andy
On Thu 22 Aug 2013 13:27, Jan Schukat <shookie <at> email.de> writes:
> 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
[Message part 3 (message/rfc822, inline)]
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
This bug report was last modified 9 years and 65 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.