On Sat, Jul 20, 2013 at 4:25 PM, Nick Wellnhofer <[email protected]> wrote:
> I think we should make it possible to create Clownfish-based projects which
> don't depend on Charmonizer.
If we can pull it off so that we don't need to install `charmony.h`, that
would be fantastic!
It's going to be challenging to do without the information captured by probes
into "charmony.h" for the headers generated by CFC, though:
* How are "inline" functions specified on the target platform?
* What's the size of an int?
* Is "stdint.h" available? How about "stdbool.h"?
* What header specifies `alloca`?
* Atomics?
* ...
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.
To achieve charmony-free autogenerated header files, I think the first thing
we would need to do is depend more heavily on C99 and build in a few special
cases for the one non-C99 compiler we support, MSVC.
#if __STDC_VERSION__ >= 199901L
#define CFISH_INLINE static inline
#elif defined(_MSC_VER)
#define CFISH_INLINE __inline
#else
#error "C99 or MSVC required"
#endif
#if __STDC_VERSION__ >= 199901L
#include <stdint.h>
#include <stdbool.h>
#elif defined(_MSC_VER)
// tricky compiler-version-specific code to define int32_t etc...
#else
#error "C99 or MSVC required"
#endif
We need atomics for LockFreeRegister, but we can probably do away with
Clownfish::Util::Atomic and use them only within LockFreeRegister.c.
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.
Marvin Humphrey
