incubator-lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <>
Subject [lucy-dev]
Date Tue, 31 May 2011 02:27:32 GMT
On Tue, May 31, 2011 at 12:55:34AM -0000, wrote:
> Author: joes
> Date: Tue May 31 00:55:34 2011
> New Revision: 1129448
> URL:
> Log:
> start a committer-use-only script to keep the charmonizer makefiles
> in sync with the src tree
> Added:
>     incubator/lucy/trunk/devel/bin/   (with props)

Summary of IRC discussion from this afternoon: 

Joe's initiative to equip Charmonizer with a canonical build system based on
Make has substantial benefits both in the long term and the short term.

  * Very little code duplication across binding languages, just system calls
    to "make".
  * Gets build code out of elegant-but-esoteric Module::Build and into a
    language that, despite its flaws, more people grok.
  * The build code is now local to Charmonizer instead of buried in a host
    language dir, so new people spelunking the code base won't be left
    scratching their head about how to make something happen.

However, the new Makefiles are more brittle than the Module::Build code --
filepaths need to be hard-coded, plus there need to be at least two Makefiles,
one for Windows and one for everywhere else.

Hand-maintaining a parallel Windows build violates DRY and I paid the price
this afternoon with a tedious debugging session.  A couple of simple typos had
outsized effects.  For instance, all files but one had their extensions
changed from .o to .obj, resulting in that one file not being cleaned up and
some weird linking errors that took me a while to research and hunt down.

When I reported back to Joe, he suggested generating the two Makefiles from a
single script, "devel/bin/".  If that sounds
familiar, that's because it's nearly identical to the plan that was discussed
back in November under the "Slow migration to Makefiles" thread:
<>  :)

So, we've arrived at essentially the same place from two different directions.
The events of today validate the approach and underline two points:

  * Windows debugging is costly.  Not that many people are either set up to do
    it or want to do it.  (I'm willing to do it because I consider it important
    dirty work, but there are a lot of other things I can be doing -- and the
    same would be true for anyone else willing to work with MSVC.)  For this
    reason, it is important that we stay true to DRY and solve problems on
    Unix whenever we can.
  * A Windows buildbot is highly desirable, as it will allow us to detect and
    isolate build problems sooner.  However, it's also laborious to set up and
    maintain Windows buildbots because of the cost of installing a dev
    enviroment and custom-compiling Perl.  Simply installing ActiveState Perl
    would work if Lucy was pure Perl, but since we are C things are more
    involved.  (Windows builds also tend to hang when memory errors occur
    rather than exit.  The Python dev list archives have insights about how to
    work around such problems.)

Marvin Humphrey

View raw message