[PATCH] Add SCons build files.

[PATCH] Add SCons build files.

[Jeffrey C. Ollie]

The SCons build files included here *should* do everything that the
current Makefiles do, plus a little bit of configuration checking.  To
build/install:

scons all emacs
sudo scons install
sudo scons install-emacs
sudo scons install-desktop

Various installation directories can be customized:

sudo scons install DESTDIR=/tmp/buildroot prefix=/opt/notmuch

See the output of 'scons -h' for a complete list of the variables that
can be modified.

Signed-off-by: Jeffrey C. Ollie <jeff@ocjtech.us>
---
 .gitignore     |    3 +
 SConstruct     |  226 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 lib/SConscript |   19 +++++
 3 files changed, 248 insertions(+), 0 deletions(-)
 create mode 100644 SConstruct
 create mode 100644 lib/SConscript

diff --git a/.gitignore b/.gitignore
index 8794354..6661b3b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -8,3 +8,6 @@ notmuch.1.gz
 *~
 .*.swp
 *.elc
+.sconsign.dblite
+.sconf_temp
+config.log
diff --git a/SConstruct b/SConstruct
new file mode 100644
index 0000000..8d6960d
--- /dev/null
+++ b/SConstruct
@@ -0,0 +1,226 @@
+# -*- mode: python; coding: utf-8 -*-
+
+import os
+
+variables = Variables('custom.py')
+
+variables.Add('DESTDIR',
+              'Destination directory',
+              '')
+
+variables.Add('prefix',
+              'Installation prefix',
+              '/usr/local')
+
+variables.Add('bindir',
+              'Directory that user binaries go into',
+              '${prefix}/bin')
+
+variables.Add('datadir',
+              'Directory that static data files go into',
+              '${prefix}/share')
+
+variables.Add('mandir',
+              'Directory that manual pages go into',
+              '${datadir}/man')
+
+variables.Add('emacs_lispdir',
+              'Directory that Emacs LISP files go into',
+              '${default_emacs_lispdir}')
+
+variables.Add('sysconfdir',
+              'Directory that system configuration files go into',
+              '/etc')
+
+variables.Add('bash_completion_dir',
+              'Directory that Bash completion files go into',
+              '${sysconfdir}/bash_completion.d')
+
+variables.Add('desktop_dir',
+              'Directory that desktop files go into',
+              '${datadir}/applications')
+
+variables.Add('gzip',
+              'Gzip executable',
+              'gzip')
+
+variables.Add('emacs',
+              'Emacs executable',
+              'emacs')
+
+def InstallPerm(env, dest, files, perm):
+    obj = env.Install(dest, files)
+    for i in obj:
+        env.AddPostAction(i, Chmod(str(i), perm))
+    return dest
+
+def InstallAsPerm(env, dest, files, perm):
+    obj = env.InstallAs(dest, files)
+    for i in obj:
+        env.AddPostAction(i, Chmod(str(i), perm))
+    return dest
+
+topenv = Environment(variables = variables,
+                     BUILDERS = {'InstallPerm': InstallPerm,
+                                 'InstallAsPerm': InstallAsPerm})
+
+topenv.Append(CPPPATH=['#/lib'])
+
+cflags = None
+if os.environ.has_key('CFLAGS'):
+    cflags = topenv.ParseFlags(os.environ['CFLAGS'])
+    topenv.MergeFlags(cflags)
+
+if os.environ.has_key('CXXFLAGS'):
+    cxxflags = topenv.ParseFlags(os.environ['CXXFLAGS'])
+    topenv.MergeFlags(cxxflags)
+
+if cflags is None or cxxflags is None:
+    optflags = topenv.ParseFlags('-O2')
+    topenv.MergeFlags(optflags)
+
+warnflags = topenv.ParseFlags('-Wall -Wextra -Wmissing-declarations -Wwrite-strings -Wswitch-enum')
+topenv.MergeFlags(warnflags)
+
+def CheckPkgConfig(context, version):
+    context.Message('Checking for pkg-config... ')
+    result = context.TryAction('pkg-config --atleast-pkgconfig-version=%s' % version)[0]
+    context.Result(result)
+    return result
+ 
+def CheckPkg(context, name):
+    context.Message('Checking for %s... ' % name)
+    result = context.TryAction('pkg-config --exists \'%s\'' % name)[0]
+    context.Result(result)
+    return result
+
+def CheckXapian(context):
+    context.Message('Checking for xapian-core... ')
+    for xapian_config in ['xapian-config-1.1', 'xapian-config']:
+        result, output = context.TryAction('%s --version > $TARGET' % xapian_config)
+        if result:
+            xapian_version = output.strip().split()[-1]
+            context.env['xapian_config'] = xapian_config
+            context.env['xapian_version'] = xapian_version
+            context.Result(xapian_version)
+            return result
+    context.Result(False)
+    return False
+
+def CheckEmacs(context):
+    context.Message('Checking for emacs... ')
+    context.env['default_emacs_lispdir'] = '${prefix}/share/emacs/site-lisp'
+    result = context.TryAction('pkg-config --exists emacs')
+    if result:
+        result, output = context.TryAction('pkg-config emacs --variable sitepkglispdir > $TARGET')
+        if result:
+            context.env['default_emacs_lispdir'] = output.strip()
+        context.Result(True)
+        return True
+    context.Result(False)
+    return False
+
+def CheckDesktopFileInstall(context):
+    context.Message('Checking for desktop-file-install... ')
+    result = context.TryAction('desktop-file-install -h')[0]
+    context.Result(result)
+    return result
+
+conf = Configure(topenv, custom_tests = {'CheckPkgConfig': CheckPkgConfig,
+                                         'CheckPkg': CheckPkg,
+                                         'CheckXapian': CheckXapian,
+                                         'CheckEmacs': CheckEmacs,
+                                         'CheckDesktopFileInstall': CheckDesktopFileInstall})
+
+if not conf.CheckPkgConfig('0.23'):
+    print 'pkg-config >= 0.23 not found.'
+    Exit(1)
+
+if not conf.CheckPkg('glib-2.0 >= 2.22'):
+    print 'glib-2.0 >= 2.22 not found'
+    Exit(1)
+
+if not conf.CheckPkg('gmime-2.4 >= 2.4.0'):
+    print 'gmime-2.4 >= 2.4.0 not found'
+    Exit(1)
+
+if not conf.CheckPkg('talloc >= 2.0.0'):
+    print 'talloc >= 2.0.0 not found'
+    Exit(1)
+
+if not conf.CheckXapian():
+    print 'xapian not found'
+    Exit(1)
+
+emacs = conf.CheckEmacs()
+
+valgrind = conf.CheckPkg('valgrind >= 3.5.0')
+
+desktop = conf.CheckDesktopFileInstall()
+
+if not conf.CheckFunc('strndup'):
+    conf.env.Append(CPPDEFINES = ['NEED_STRNDUP'])
+
+if not conf.CheckFunc('getline'):
+    conf.env.Append(CPPDEFINES = ['NEED_GETLINE'])
+
+topenv = conf.Finish()
+
+topenv.ParseConfig('pkg-config glib-2.0 --cflags --libs')
+topenv.ParseConfig('pkg-config gmime-2.4 --cflags --libs')
+topenv.ParseConfig('pkg-config talloc --cflags --libs')
+topenv.ParseConfig('${xapian_config} --cxxflags --libs')
+if valgrind:
+    topenv.ParseConfig('pkg-config valgrind --cflags')
+    topenv.Append(CPPDEFINES = ['HAVE_VALGRIND'])
+
+Help(variables.GenerateHelpText(topenv))
+
+Export('topenv')
+
+libnotmuch = SConscript(['lib/SConscript'])
+
+env = topenv.Clone()
+
+notmuch = env.Program('notmuch', ['debugger.c',
+                                  'gmime-filter-reply.c',
+                                  'notmuch.c',
+                                  'notmuch-config.c',
+                                  'notmuch-dump.c',
+                                  'notmuch-new.c',
+                                  'notmuch-reply.c',
+                                  'notmuch-restore.c',
+                                  'notmuch-search.c',
+                                  'notmuch-setup.c',
+                                  'notmuch-show.c',
+                                  'notmuch-tag.c',
+                                  'notmuch-time.c',
+                                  'query-string.c',
+                                  'show-message.c',
+                                  libnotmuch])
+env.Alias('all', notmuch)
+
+env.Install('${DESTDIR}${bindir}', notmuch)
+env.Alias('install', '${DESTDIR}${bindir}')
+
+manpage = env.Command('notmuch.1.gz', 'notmuch.1', '${gzip} -9 < $SOURCE > $TARGET')
+env.Alias('all', manpage)
+
+env.InstallPerm('${DESTDIR}${mandir}/man1', manpage, 0644)
+env.Alias('install', '${DESTDIR}${mandir}/man1')
+
+env.InstallAsPerm('${DESTDIR}${bash_completion_dir}/notmuch', 'contrib/notmuch-completion.bash', 0644)
+env.Alias('install', '${DESTDIR}${bash_completion_dir}')
+
+if desktop:
+    env.Command('${DESTDIR}${desktop_dir}/notmuch.desktop', 'notmuch.desktop', 'desktop-file-install --mode 0644 --dir ${DESTDIR}${desktop_dir} ${SOURCE}')
+    env.Alias('install-desktop', '${DESTDIR}${desktop_dir}')
+
+if emacs:
+    elisp = env.Command('notmuch.elc', 'notmuch.el', '${emacs} --no-window-system --no-site-file --no-init-file --no-splash --batch --funcall batch-byte-compile $SOURCE')
+    env.Alias('emacs', elisp)
+    env.InstallPerm('${DESTDIR}${emacs_lispdir}', elisp, 0644)
+    env.InstallPerm('${DESTDIR}${emacs_lispdir}', 'notmuch.el', 0644)
+    env.Alias('install-emacs', '${DESTDIR}${emacs_lispdir}')
+
+Default('all')
diff --git a/lib/SConscript b/lib/SConscript
new file mode 100644
index 0000000..eb38516
--- /dev/null
+++ b/lib/SConscript
@@ -0,0 +1,19 @@
+# -*- mode: python; coding: utf-8 -*-
+
+Import('topenv')
+
+env = topenv.Clone()
+
+libnotmuch = env.Library('notmuch', ['libsha1.c',
+                                     'message-file.c',
+                                     'messages.c',
+                                     'sha1.c',
+                                     'tags.c',
+                                     'xutil.c',
+                                     'database.cc',
+                                     'index.cc',
+                                     'message.cc',
+                                     'query.cc',
+                                     'thread.cc'])
+
+Return('libnotmuch')
-- 
1.6.5.2

Re: [PATCH] Add SCons build files.

[Bart Trojanowski]

* Jeffrey C. Ollie <jeff@ocjtech.us> [091122 08:47]:
> The SCons build files included here *should* do everything that the
> current Makefiles do, plus a little bit of configuration checking.  To
> build/install:

Wouldn't that have the unfortunate side effect of making notmuch
unusable w/o emacs and scons installed?

GNU make has a much wider install base, and notmuch is still very useful
without emacs.

-Bart

-- 
				WebSig: http://www.jukie.net/~bart/sig/

Re: [PATCH] Add SCons build files.

[Jeffrey Ollie]

The SCons build files are not meant to require emacs.  If I've messed
something up and emacs is somehow required I would consider that a bug
and would try to fix it.

As far as availability, I'm sure that SCons is one yum or apt-get or
<insert other package management system command> away.   The only
people that would face more than a minor inconvenience are people that
prefer to download tarballs and compile and install things themselves.

Yes, I'm sure that make is widely available, but as notmuch gets used
on a wider variety of systems some sort of configuration system will
become necessary.  If I can prevent another project from going down
the autoconf/automake path I'll be happy.  I started creating CMake
build files but I don't know CMake well enough to come up with a
working build.

On 11/22/09, Bart Trojanowski <bart@jukie.net> wrote:
> * Jeffrey C. Ollie <jeff@ocjtech.us> [091122 08:47]:
>> The SCons build files included here *should* do everything that the
>> current Makefiles do, plus a little bit of configuration checking.  To
>> build/install:
>
> Wouldn't that have the unfortunate side effect of making notmuch
> unusable w/o emacs and scons installed?
>
> GNU make has a much wider install base, and notmuch is still very useful
> without emacs.
>
> -Bart
>
> --
> 				WebSig: http://www.jukie.net/~bart/sig/
>

-- 
Sent from my mobile device

Jeff Ollie

Re: [PATCH] Add SCons build files.

[Jed Brown]

On Sun, 22 Nov 2009 10:00:26 -0600, Jeffrey Ollie <jeff@ocjtech.us> wrote:

> Yes, I'm sure that make is widely available, but as notmuch gets used
> on a wider variety of systems some sort of configuration system will
> become necessary.  If I can prevent another project from going down
> the autoconf/automake path I'll be happy.  I started creating CMake
> build files but I don't know CMake well enough to come up with a
> working build.

I can do a CMake build if that's desirable.  While I prefer it to SCons,
particularly when config/build times are an issue and you want to have
several active build trees, it is a significantly heavier dependency.
With SCons, you can dump scons-local (a pure Python script) into the
source tree and then users only need Python.  There are lots of other
lightweight build tools.

Jed

Re: [PATCH] Add SCons build files.

[Jeffrey Ollie]

On Sun, Nov 22, 2009 at 11:21 AM, Jed Brown <jed@59a2.org> wrote:
>
> I can do a CMake build if that's desirable.  While I prefer it to SCons,
> particularly when config/build times are an issue and you want to have
> several active build trees, it is a significantly heavier dependency.
> With SCons, you can dump scons-local (a pure Python script) into the
> source tree and then users only need Python.  There are lots of other
> lightweight build tools.

It would be interesting to compare SCons and CMake.  CMake is probably
more widely used since it's adoption by KDE but I like the fact that
SCons build scripts are lightly camouflaged Python scripts.  CMake's
syntax has so far seemed to get in the way of me figuring out what I
needed to do.

While I prefer SCons, I wouldn't be unhappy if CMake was chosen.

-- 
Jeff Ollie

Re: [PATCH] Add SCons build files.

[Bart Trojanowski]

My bad.  I totally misread your introduction.

* Jeffrey Ollie <jeff@ocjtech.us> [091122 11:46]:
> The SCons build files are not meant to require emacs.  If I've messed
> something up and emacs is somehow required I would consider that a bug
> and would try to fix it.
> 
> As far as availability, I'm sure that SCons is one yum or apt-get or
> <insert other package management system command> away.   The only
> people that would face more than a minor inconvenience are people that
> prefer to download tarballs and compile and install things themselves.
> 
> Yes, I'm sure that make is widely available, but as notmuch gets used
> on a wider variety of systems some sort of configuration system will
> become necessary.  If I can prevent another project from going down
> the autoconf/automake path I'll be happy.  I started creating CMake
> build files but I don't know CMake well enough to come up with a
> working build.
> 
> On 11/22/09, Bart Trojanowski <bart@jukie.net> wrote:
> > * Jeffrey C. Ollie <jeff@ocjtech.us> [091122 08:47]:
> >> The SCons build files included here *should* do everything that the
> >> current Makefiles do, plus a little bit of configuration checking.  To
> >> build/install:
> >
> > Wouldn't that have the unfortunate side effect of making notmuch
> > unusable w/o emacs and scons installed?
> >
> > GNU make has a much wider install base, and notmuch is still very useful
> > without emacs.
> >
> > -Bart
> >
> > --
> > 				WebSig: http://www.jukie.net/~bart/sig/
> >
> 
> -- 
> Sent from my mobile device
> 
> Jeff Ollie

-- 
				WebSig: http://www.jukie.net/~bart/sig/

Re: [PATCH] Add SCons build files.

[Ingmar Vanhassel]

Personally I'd say we have better things to work on than maintaining
multiple buildsystems for notmuch. Or than resolving possible packaging
bugs originating in the use of different buildsystems.

GNU has a very wide install bas, it's has a low footprint,  and it
happened to be the choice of the initial developers. All of this makes
it the best choice imo.

While I don't want to start a discussion on the merits of various
buildsystems, I'll mention that, in my role as a packager, I'd choose
just about anything over scons.

My 2 cents,
Ingmar

-- 
Exherbo KDE, X.org maintainer

Re: [PATCH] Add SCons build files.

[Carl Worth]

On Sun, 22 Nov 2009 07:47:10 -0600, "Jeffrey C. Ollie" <jeff@ocjtech.us> wrote:
> The SCons build files included here *should* do everything that the
> current Makefiles do, plus a little bit of configuration checking.  To
> build/install:

Hi Jeffrey,

Thanks for your effort to code all this up.

But I'm afraid I really don't want to switch away from just using (GNU)
make for the actual compilation.

I don't know anything about scons, but if you can use it to write a
python script that just does the configuration step, (outputting a
Makefile.config say), then that might be very interesting. Some people
have recently told me that python would be a much more sane language for
doing configuration in than shell.

I don't know if they're right or not, but I'm (somewhat) willing to have
multiple implementations of the configure script (since there's always
the option to just skip it and configure Makefile.config manually). But
I'm definitely not willing to have multiple build systems.

> Yes, I'm sure that make is widely available, but as notmuch gets used
> on a wider variety of systems some sort of configuration system will
> become necessary.  If I can prevent another project from going down
> the autoconf/automake path I'll be happy.  I started creating CMake
> build files but I don't know CMake well enough to come up with a
> working build.

I'm totally glad to try to avoid autoconf/automake. I know for sure that
I never want to use libtool again, (I've learned that the hard way). I
don't have as much prejudice against automake, but I've heard a rumor
that it's hard to make it *not* use libtool.

Meanwhile, the only advantage I know for automake is that once it's
setup, adding a new file to compile is as simple as adding one file to a
list in the Makefile.am. We've already got notmuch as easy as that with
just adding a file to a list in Makefile.local.

So then all that's left is a configuration system. The notion of how the
final "configure" script from autoconf works seems just fine to me, but
I'm not sure the implementation of autoconf itself is sound. I've been
maintaining a project for years (cairo) where the m4-complexity in
configure.ac has far outgrown my ability to understand it. And I'm
extremely uncomfortable with a build system I can't understand.

Meanwhile, cairo *still* has a shell script needed just to bootstrap the
autconf/automake/libtool house of cards, and that shell script alone is
194 lines.

So I'd very much like to continue exploring what we can do with our own
configuration system, (in whatever language/language(s) make sense). In
the meantime, I'm happy that I can just checkout and build notmuch on a
Linux system with no configure step at all. I also like that the
build-system doesn't trigger constant re-runs of configure all the
time. I've spent too many days of my life watching autoconf output
scroll by, and I'd really like to avoid going down that road.

So yes, Jeffrey, if avoiding autoconf is the motivation, then I'm right
there with you. But I'm not convinced that throwing out GNU make is the
right thing to do as well.

Thanks for listening,

-Carl

Re: [PATCH] Add SCons build files.

[Jeffrey Ollie]

On Sun, Nov 22, 2009 at 9:11 PM, Carl Worth <cworth@cworth.org> wrote:
>
> But I'm afraid I really don't want to switch away from just using (GNU)
> make for the actual compilation.
>
> I don't know anything about scons, but if you can use it to write a
> python script that just does the configuration step, (outputting a
> Makefile.config say), then that might be very interesting.

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

If you really want a tool that generates Makefiles, take a look at
CMake.  Unfortunately, I think CMake tries to do too much with the
Makefiles and they become close to unreadable.  In the attempt I made
to come up with CMake build files, CMake generates at least 3800 lines
of Makefiles (from a starting point of 30 lines of build files).

> Some people
> have recently told me that python would be a much more sane language for
> doing configuration in than shell.

Well, Python is a much more sane language for doing just about
anything as far as I'm concerned. :)

> I don't know if they're right or not, but I'm (somewhat) willing to have
> multiple implementations of the configure script (since there's always
> the option to just skip it and configure Makefile.config manually). But
> I'm definitely not willing to have multiple build systems.

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.

> Meanwhile, the only advantage I know for automake is that once it's
> setup, adding a new file to compile is as simple as adding one file to a
> list in the Makefile.am. We've already got notmuch as easy as that with
> just adding a file to a list in Makefile.local.

Once SCons is set up, adding a new file is just a matter of adding the
name of the file to a list as well.  CMake is the same, and I'm sure
that other systems are similar.

> So I'd very much like to continue exploring what we can do with our own
> configuration system, (in whatever language/language(s) make sense).

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

> Thanks for listening,

Same here.

-- 
Jeff Ollie

Re: [PATCH] Add SCons build files.

[Carl Worth]

On Sun, 22 Nov 2009 22:36:30 -0600, Jeffrey Ollie <jeff@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