9c/5de62393e23ba2e08e3232abd3cd7417ef89a5

   1 Return-Path: <cworth@cworth.org>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id 5B73B431FC3;\r
   6         Sun, 22 Nov 2009 22:21:08 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 Received: from olra.theworths.org ([127.0.0.1])\r
   9         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  10         with ESMTP id JzkxKY9StBWJ; Sun, 22 Nov 2009 22:21:07 -0800 (PST)\r
  11 Received: from cworth.org (localhost [127.0.0.1])\r
  12         by olra.theworths.org (Postfix) with ESMTP id 1C0FC431FBC;\r
  13         Sun, 22 Nov 2009 22:21:06 -0800 (PST)\r
  14 From: Carl Worth <cworth@cworth.org>\r
  15 To: Jeffrey Ollie <jeff@ocjtech.us>\r
  16 In-Reply-To: <935ead450911222036o141956e0o11056c9d7a45781b@mail.gmail.com>\r
  17 References: <1258897630-22282-1-git-send-email-jeff@ocjtech.us>\r
  18         <87y6lyexz8.fsf@yoom.home.cworth.org>\r
  19         <935ead450911222036o141956e0o11056c9d7a45781b@mail.gmail.com>\r
  20 Date: Mon, 23 Nov 2009 07:20:52 +0100\r
  21 Message-ID: <874ool224b.fsf@yoom.home.cworth.org>\r
  22 MIME-Version: 1.0\r
  23 Content-Type: text/plain; charset=us-ascii\r
  24 Cc: Not Much Mail <notmuch@notmuchmail.org>\r
  25 Subject: Re: [notmuch] [PATCH] Add SCons build files.\r
  26 X-BeenThere: notmuch@notmuchmail.org\r
  27 X-Mailman-Version: 2.1.12\r
  28 Precedence: list\r
  29 List-Id: "Use and development of the notmuch mail system."\r
  30         <notmuch.notmuchmail.org>\r
  31 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  32         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  33 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  34 List-Post: <mailto:notmuch@notmuchmail.org>\r
  35 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  36 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  37         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  38 X-List-Received-Date: Mon, 23 Nov 2009 06:21:08 -0000\r
  39 \r
  40 On Sun, 22 Nov 2009 22:36:30 -0600, Jeffrey Ollie <jeff@ocjtech.us> wrote:\r
  41 > Well, to me, part of the appeal of SCons is that it doesn't generate\r
  42 > Makefiles.    This article is a little old, but the first three\r
  43 > sections are a pretty good rundown on the limitations of Make.\r
  44 > \r
  45 > http://www.scons.org/wiki/FromMakeToScons\r
  46 \r
  47 Not very convincing to me at least. Half of it is limitations of various\r
  48 make implementations, (notmuch is definitely not trying to be portable\r
  49 across those---it uses GNU make). The other half is about problems in\r
  50 how make is often used, (like slow recursive make runs, or incomplete\r
  51 dependencies---but we've got a nice non-recursive make setup in notmuch\r
  52 and good dependency generation).\r
  53 \r
  54 It is true that make is doing timestamp-based checks rather than\r
  55 content-based, but things like this are things that people are quite\r
  56 familiar in deailing with.\r
  57 \r
  58 > If you really want a tool that generates Makefiles, take a look at\r
  59 > CMake.\r
  60 \r
  61 No I don't want a tool to generate Makefiles. I want to write the\r
  62 Makefiles, (which I've done). I'm willing to have a tool to create the\r
  63 configuration, (really just some variables accessible at\r
  64 compile-time). Right now we're storing these in a Makefile snippet named\r
  65 "Makefile.config" but we could just as easily be putting them in\r
  66 "config.h".\r
  67 \r
  68 > I think that having multiple different configuration systems would be\r
  69 > pretty awful, especially if people make changes to their favourite\r
  70 > configuration system and hope that someone else fixes the others.\r
  71 \r
  72 It's early times. I'm willing to entertain different ideas and have\r
  73 people propose different means of doing the configure step. Long-term\r
  74 we'll likely only have one supported thing.\r
  75 \r
  76 > It would seem to me that we would be re-inventing a lot of the work\r
  77 > already done by other people.\r
  78 \r
  79 But there's really so little to invent here. It's just not that hard to\r
  80 do the kinds of configuration that notmuch needs. So far we've got a few\r
  81 pkg-config checks and that gets us a long ways. Beyond that, the only\r
  82 portability improvements requested so far will require only the\r
  83 following from configure:\r
  84 \r
  85   * Find which of the compiler warning flags we want are available.\r
  86 \r
  87   * Find whether we have some particular library functions are\r
  88     available.\r
  89 \r
  90 And for these steps, all we have to do is to *compile* some test\r
  91 programs. And compiling programs is something our build system knows how\r
  92 to do already (since that's all it does). So I'm just not seeing that\r
  93 we'll spend much time reinventing anything.\r
  94 \r
  95 -Carl\r