lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <mar...@rectangular.com>
Subject Monolithic Charmonizer files
Date Tue, 05 Jan 2010 22:47:19 GMT
Greets,

Nate mentioned a little while back that it wasn't obvious how you would go
about building Charmonizer as a standalone entity -- no Makefile.

Here's the problem, though: cross-platform compatible Makefiles are a
headache, because operating systems and build systems differ so widely.  It's
inevitable that we'll end up with multiple Makefiles if we go down that path.
And that will mean duplicated work for us, since we also have to solve the
platform-compatibility problem for each of Lucy's hosts.  

So, here's an alternative strategy: 

  * Put everything under Charmonizer/Core/ and Charmonizer/Probe/ into one
    file, "charmonizer.c".  
  * Put everything under Charmonizer/Test/ into another file,
    "test_charmony.c".  
  * Either no Makefile, or a bare-bones Makefile that works on a few systems
    but is easily dispensed with.

To use Charmonizer, follow these steps:

  1. Compile "charmonizer.c" to an executable.
  2. Run the charmonizer executable, generating "charmony.h".
  3. Optionally, build "test_charmony.c" and run it.

Right now, all the .c and .h files within Charmonizer/Core/ and
Charmonizer/Probe/ add up to 4,440 lines and 120 kB.  For comparison, the
SQLite core is distributed as a single amalgamated C file clocking in at
around 111,000 lines and 3.7 MB.  Also of interest: the "Configure" script
distributed with Perl 5.10.1 is around 22,000 lines and 508 kB.

At its present size, we should just consolidate and work on the consolidated
files directly.  Compiling as a monolithic file is plenty fast.

If Charmonizer ever escapes from Lucy's orbit and becomes an independent
project, it will have to grow quite a bit and support a lot more features; I
can foresee a time when it could become inconvenient to develop Charmonizer as
a monolithic file because of compilation time following small edits.  If that
ever becomes a problem, we can mimic the SQLite dev process: build modularly
during development, then amalgamate before the distribution is prepared.  For
now, though, compilation time isn't a concern.

There would be some minor fallout from choosing this plan of action: right now
the Lucy core uses the Charmonizer test framework, which would become private.
However, TAP-producing test frameworks are easy, and I've been thinking about
giving the Lucy core one of its own, anyway, to make it easier to use Lucy
objects in the test output.

Thoughts?

Marvin Humphrey


Mime
View raw message