Return-Path: X-Original-To: notmuch@notmuchmail.org Delivered-To: notmuch@notmuchmail.org Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 5B73B431FC3; Sun, 22 Nov 2009 22:21:08 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JzkxKY9StBWJ; Sun, 22 Nov 2009 22:21:07 -0800 (PST) Received: from cworth.org (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 1C0FC431FBC; Sun, 22 Nov 2009 22:21:06 -0800 (PST) From: Carl Worth To: Jeffrey Ollie In-Reply-To: <935ead450911222036o141956e0o11056c9d7a45781b@mail.gmail.com> References: <1258897630-22282-1-git-send-email-jeff@ocjtech.us> <87y6lyexz8.fsf@yoom.home.cworth.org> <935ead450911222036o141956e0o11056c9d7a45781b@mail.gmail.com> Date: Mon, 23 Nov 2009 07:20:52 +0100 Message-ID: <874ool224b.fsf@yoom.home.cworth.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Not Much Mail Subject: Re: [notmuch] [PATCH] Add SCons build files. X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2009 06:21:08 -0000 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