On Sun, Jul 21, 2013 at 12:32 PM, Nick Wellnhofer <[email protected]> wrote:
> 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.
OK, that works.
> This would essentially be a minimal version of charmony.h
> which uses the CFISH namespace.
Sounds good. A while back I made some changes to Charmonizer in anticipation
of supporting custom prefixes (swapping out ConfWriter_append_conf in most of
the probes for functions like ConfWriter_add_def).
> One of the problems I see with installing
> charmony.h is that it would clash with other user-generated versions.
The issue is very similar to the issue of installing a config.h file generated
by Autoconf.
http://inaugust.com/post/68
https://issues.apache.org/jira/browse/THRIFT-705
http://www.gnu.org/software/autoconf-archive/ax_prefix_config_h.html
I say "similar" rather than "identical" because in some ways Charmonizer is
still attached to Clownfish the way Metaconfig is to Perl. If Metaconfig had
clients other than Perl, it would need prefixes, too.
Perl gets away with installing a config.h file into
"$Config{installarchlib}/CORE", and Clownfish can get away with it too. But
it complicates things and if Clownfish's headers can become completely
platform agnostic, that would be great.
> And I really don't want to force our users to always build charmony.h
> themselves.
Yes, absolutely.
Let's bear in mind that even if Charmonizer was always intended to be a
distinct layer -- and potentially an independent product, if justified by
user/developer interest -- it has evolved as support for a single distro.
This kind of weirdness is to be expected. I'm glad we're cleaning things up!
> 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.
>
> 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.
There may be creative solutions for those that prove difficult.
For instance, we can simply remove endianness from all public headers.
Endianness isn't needed by Clownfish, only Lucy -- in fact, the entire
Clownfish::Util::NumberUtils module shouldn't really be part of Clownfish, as
it's barely used outside of Lucy. To solve the problem, we can move the
endian macros into an optional Charmonizer probe, so that they are defined
only in a Lucy-specific charmony.h file which does not get installed.
Marvin Humphrey
