Ingo Oeser <[EMAIL PROTECTED]> writes: > > To compile my application for all supported platforms, I would need to > > collect all these header files and wrap them with appropriate > > #ifdef's, right? Or else, I could put them in subdirectories and > > select the right one at ./configure time. > > Yes, there is no other way to include that kind of code. > This kind of code should actually be in the compiler, but they > don't seem to care.
Surely not the compiler, itself. Perhaps in a compiler-related library. Or, maybe glibc could export this stuff. Actually, my Debian system has two copies in different C++ header directories, probably because I have several compiler packages installed... libstdc++5-dev: /usr/include/c++/3.2/i386-linux/bits/atomicity.h libstdc++3-dev: /usr/include/g++-v3/i386-linux/bits/atomicity.h I would actually prefer a separate LGPL-ed package supporting as many architectures as reasonably possible. That would make application code easier to port to non-GCC, non-glibc, or non-Linux platforms. The main reason I don't want to include all these files in my own sources is that I have no reasonable way to test or maintain all those snippets of assembler language for exotic machines to which I have no access. I'd love to see a small team with access to a suite of test machines step up to supporting these functions on as many machines as possible. I wouldn't mind doing a lot of that work, myself. But I couldn't do an adequate job without access to additional resources and help from people familiar with various processor architectures. A carefully chosen set of these header files with a library of test cases and good documentation would be a valuable resource for the open software community in general, and LAD in particular. In fact, I'm surprised no one has done this already. I guess people with the needed expertise and access to those sorts of machine resources have bigger fish to fry. Regards, -- Jack O'Quin Austin, Texas, USA
