On Jul 21, 2013, at 20:40 , Marvin Humphrey <[email protected]> wrote:
> This approach is problematic, IMO: > > > https://git-wip-us.apache.org/repos/asf?p=lucy.git;a=commitdiff;h=c2ff0a87846f54d32c5928a4775470a167b74bf5 > > After that commit, the content of headers autogenerated by CFC depends on the > system where CFC was built, not the platform where the extension is to be > used. Techniques such as cross-compiling won't work. As far as I know, the > output autogenerated by CFC right now is deterministic based solely on the > .cfh input files -- I think we should preserve this invariant. OK, I can change that, although the CFC output should never change on the same platform. Besides, I already introduced platform-dependent code in cfish_parcel.h. But we can put the platform-dependent parts in a separate header file like cfish_platform.h. This would essentially be a minimal version of charmony.h which uses the CFISH namespace. One of the problems I see with installing charmony.h is that it would clash with other user-generated versions. And I really don't want to force our users to always build charmony.h themselves. Then we could add the option to provide a special cfish_platform.h for a different platform to enable cross-compiling, but I don't think this should be a concern for now. > We need atomics for LockFreeRegister, but we can probably do away with > Clownfish::Util::Atomic and use them only within LockFreeRegister.c. Other platform-specific things we currently use in the generated code: * (Emulated) C99 bool type * (Emulated) C99 integer types * alloca * Variadic macros * Endianness * __func__ macro * Symbol visibility * u64 to double conversion for MSVC6 I'm not sure we can derive all that from macros set by the compiler. > It would also be nice if for MSVC we didn't require compilation in C++ mode. > We might choose to require it for both the Clownfish runtime and Lucy > (because we want line comments and mixed declarations and code in our > implementation files), but we shouldn't impose that requirement on extensions > if we can help it. I don't see a problem with that. The generated code should already be C89-compliant. We probably missed a few things but that should be easy to fix. Nick
