With some MacOS help from Nate, I've begun the conversion of LLVM to use
lib/System, the operating system independence layer. Currently, the
library has implementations for three abstractions: Path, Program, and
Signals. These provide some basic utilities for manipulating file system
paths, finding and executing programs, and cleaning up after Signals.
The implementations should work on most Unix systems. Linux and MacOS
are already verified.
The implementation of the lib/System interface should work on Solaris,
BSD, and perhaps a few other Unix systems. If you run into problems,
please let me know. Right now, the only thing that should affect any
tool other than llvmc is the RemoveFileOnSignal and
PrintStackTraceOnErrorSignal functions. These have been moved out of
lib/Support and into lib/System.
Until I can get some hardware for each kind of system (should happen
this fall), I would like to ask for volunteers to assist in the testing
and porting of lib/System to: Darwin, Solaris 8/9, AIX, Cygwin, BSD 4.X
and Win32 platforms. I would like to see LLVM some day soon run natively
on Win32 platforms without the use of Cygwin. This requires a complete
conversion of LLVM to use lib/System and then porting of lib/System to
Win32. Does anyone want to volunteer for the port? My Win32 knowledge is
pretty rusty (circa 1997).
Can I get a volunteer on each platform? I was thinking:
Darwin: Nate
Solaris: Brian
BSD: Vladimir M
AIX: Misha ?
Cygwin: ?
Win32: ?
*All* you need to do is notice when I make changes to lib/System and
then update, reconfigure, and compile lib/System (as checked in), run
the lib/System test suite, and send me the results. If anything breaks,
I'll figure out what needs to change and patch it (for Unix systems).
With some MacOS help from Nate, I've begun the conversion of LLVM to use
lib/System, the operating system independence layer. Currently, the
library has implementations for three abstractions: Path, Program, and
Signals.
Did you consider using boost::filesystem for Path abstraction? See the
documentation on:
The LLVM source base used to be dependent on boost but we have removed
that dependency because it had a high cost for the relatively small
portions of it that we needed. boost is a general purpose C++ library
that happens to handle filesystem things in a somewhat portable way.
However, lib/System will handle signals, memory mapped files, program
execution, and several other things that boost does not provide.
Additionally, as compilers go, we'll probably end up supporting some
esoteric platforms (Interix is already on the way) that boost does not
support.
I imagine that if we need more of the kinds of things boost provides
that we should revisit our design goal to remove boost from LLVM but I
don't think we're there yet.
With some MacOS help from Nate, I've begun the conversion of LLVM to use
lib/System, the operating system independence layer.
FYI, I'm getting this on an up-to-date tree:
Compiling Path.cpp
In file included from platform/Path.cpp:20,
from Path.cpp:37:
platform/../Unix/Path.cpp: In static member function `static llvm::sys::Path
llvm::sys::Path::GetTemporaryDirectory()':
platform/../Unix/Path.cpp:54: error: `assert' undeclared (first use this
function)
The LLVM source base used to be dependent on boost but we have removed
that dependency because it had a high cost for the relatively small
portions of it that we needed.
What's exactly was that high cost. Is that large size of boost itself, or some
other problems.
boost is a general purpose C++ library
that happens to handle filesystem things in a somewhat portable way.
However, lib/System will handle signals, memory mapped files, program
execution, and several other things that boost does not provide.
I understand, and was suggesting only boost::filesystem. On the other hand,
I'm sure "other things" will be interesting to the boost folks as well, and
your code might form a basic of a new boost library.
Additionally, as compilers go, we'll probably end up supporting some
esoteric platforms (Interix is already on the way) that boost does not
support.
What kind of a system Interix is If it's POSIX with recent gcc, then I don't
except any problems whatsoever. Even if it's not POSIX, but has decent
compiler, I'm sure the relevant changes for boost::filesystem can be made and
if someone is willing to do the testing, I'll be able to get the patches into
boost CVS.
I imagine that if we need more of the kinds of things boost provides
that we should revisit our design goal to remove boost from LLVM but I
don't think we're there yet.