[notmuch] [PATCH] Add SCons build files.
On Sun, 22 Nov 2009 22:36:30 -0600, Jeffrey Ollie 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
[notmuch] [PATCH] Add SCons build files.
On Sun, 22 Nov 2009 07:47:10 -0600, "Jeffrey C. Ollie" 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
[notmuch] [PATCH] Add SCons build files.
On Sun, Nov 22, 2009 at 9:11 PM, Carl Worth 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
[notmuch] [PATCH] Add SCons build files.
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
[notmuch] [PATCH] Add SCons build files.
On Sun, 22 Nov 2009 10:00:26 -0600, Jeffrey Ollie 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
[notmuch] [PATCH] Add SCons build files.
My bad. I totally misread your introduction. * Jeffrey Ollie [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 > 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 wrote: > > * Jeffrey C. Ollie [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/
[notmuch] [PATCH] Add SCons build files.
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 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 wrote: > * Jeffrey C. Ollie [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
[notmuch] [PATCH] Add SCons build files.
* Jeffrey C. Ollie [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/
[notmuch] [PATCH] Add SCons build files.
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
---
.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 000..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):
+
