[notmuch] [PATCH] Add SCons build files.

[Carl Worth]

On Sun, 22 Nov 2009 22:36:30 -0600, Jeffrey Ollie <jeff at ocjtech.us> wrote:
> Well, to me, part of the appeal of SCons is that it doesn't generate
> Makefiles.    This article is a little old, but the first three
> sections are a pretty good rundown on the limitations of Make.
> 
> http://www.scons.org/wiki/FromMakeToScons

Not very convincing to me at least. Half of it is limitations of various
make implementations, (notmuch is definitely not trying to be portable
across those---it uses GNU make). The other half is about problems in
how make is often used, (like slow recursive make runs, or incomplete
dependencies---but we've got a nice non-recursive make setup in notmuch
and good dependency generation).

It is true that make is doing timestamp-based checks rather than
content-based, but things like this are things that people are quite
familiar in deailing with.

> If you really want a tool that generates Makefiles, take a look at
> CMake.

No I don't want a tool to generate Makefiles. I want to write the
Makefiles, (which I've done). I'm willing to have a tool to create the
configuration, (really just some variables accessible at
compile-time). Right now we're storing these in a Makefile snippet named
"Makefile.config" but we could just as easily be putting them in
"config.h".

> I think that having multiple different configuration systems would be
> pretty awful, especially if people make changes to their favourite
> configuration system and hope that someone else fixes the others.

It's early times. I'm willing to entertain different ideas and have
people propose different means of doing the configure step. Long-term
we'll likely only have one supported thing.

> It would seem to me that we would be re-inventing a lot of the work
> already done by other people.

But there's really so little to invent here. It's just not that hard to
do the kinds of configuration that notmuch needs. So far we've got a few
pkg-config checks and that gets us a long ways. Beyond that, the only
portability improvements requested so far will require only the
following from configure:

  * Find which of the compiler warning flags we want are available.

  * Find whether we have some particular library functions are
    available.

And for these steps, all we have to do is to *compile* some test
programs. And compiling programs is something our build system knows how
to do already (since that's all it does). So I'm just not seeing that
we'll spend much time reinventing anything.

-Carl