4e/0069de64ebdcc31aa0a298cf19595677846cf3

   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 672F4431FC0;\r
   6         Sun, 22 Nov 2009 19:12:11 -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 kQQ1D2yQXwXu; Sun, 22 Nov 2009 19:12:10 -0800 (PST)\r
  11 Received: from cworth.org (localhost [127.0.0.1])\r
  12         by olra.theworths.org (Postfix) with ESMTP id F0C17431FAE;\r
  13         Sun, 22 Nov 2009 19:12:09 -0800 (PST)\r
  14 From: Carl Worth <cworth@cworth.org>\r
  15 To: "Jeffrey C. Ollie" <jeff@ocjtech.us>, Not Much Mail\r
  16         <notmuch@notmuchmail.org>\r
  17 In-Reply-To: <1258897630-22282-1-git-send-email-jeff@ocjtech.us>\r
  18 References: <1258897630-22282-1-git-send-email-jeff@ocjtech.us>\r
  19 Date: Mon, 23 Nov 2009 04:11:55 +0100\r
  20 Message-ID: <87y6lyexz8.fsf@yoom.home.cworth.org>\r
  21 MIME-Version: 1.0\r
  22 Content-Type: text/plain; charset=us-ascii\r
  23 Subject: Re: [notmuch] [PATCH] Add SCons build files.\r
  24 X-BeenThere: notmuch@notmuchmail.org\r
  25 X-Mailman-Version: 2.1.12\r
  26 Precedence: list\r
  27 List-Id: "Use and development of the notmuch mail system."\r
  28         <notmuch.notmuchmail.org>\r
  29 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  30         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  31 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  32 List-Post: <mailto:notmuch@notmuchmail.org>\r
  33 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  34 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  35         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  36 X-List-Received-Date: Mon, 23 Nov 2009 03:12:11 -0000\r
  37 \r
  38 On Sun, 22 Nov 2009 07:47:10 -0600, "Jeffrey C. Ollie" <jeff@ocjtech.us> wrote:\r
  39 > The SCons build files included here *should* do everything that the\r
  40 > current Makefiles do, plus a little bit of configuration checking.  To\r
  41 > build/install:\r
  42 \r
  43 Hi Jeffrey,\r
  44 \r
  45 Thanks for your effort to code all this up.\r
  46 \r
  47 But I'm afraid I really don't want to switch away from just using (GNU)\r
  48 make for the actual compilation.\r
  49 \r
  50 I don't know anything about scons, but if you can use it to write a\r
  51 python script that just does the configuration step, (outputting a\r
  52 Makefile.config say), then that might be very interesting. Some people\r
  53 have recently told me that python would be a much more sane language for\r
  54 doing configuration in than shell.\r
  55 \r
  56 I don't know if they're right or not, but I'm (somewhat) willing to have\r
  57 multiple implementations of the configure script (since there's always\r
  58 the option to just skip it and configure Makefile.config manually). But\r
  59 I'm definitely not willing to have multiple build systems.\r
  60 \r
  61 > Yes, I'm sure that make is widely available, but as notmuch gets used\r
  62 > on a wider variety of systems some sort of configuration system will\r
  63 > become necessary.  If I can prevent another project from going down\r
  64 > the autoconf/automake path I'll be happy.  I started creating CMake\r
  65 > build files but I don't know CMake well enough to come up with a\r
  66 > working build.\r
  67 \r
  68 I'm totally glad to try to avoid autoconf/automake. I know for sure that\r
  69 I never want to use libtool again, (I've learned that the hard way). I\r
  70 don't have as much prejudice against automake, but I've heard a rumor\r
  71 that it's hard to make it *not* use libtool.\r
  72 \r
  73 Meanwhile, the only advantage I know for automake is that once it's\r
  74 setup, adding a new file to compile is as simple as adding one file to a\r
  75 list in the Makefile.am. We've already got notmuch as easy as that with\r
  76 just adding a file to a list in Makefile.local.\r
  77 \r
  78 So then all that's left is a configuration system. The notion of how the\r
  79 final "configure" script from autoconf works seems just fine to me, but\r
  80 I'm not sure the implementation of autoconf itself is sound. I've been\r
  81 maintaining a project for years (cairo) where the m4-complexity in\r
  82 configure.ac has far outgrown my ability to understand it. And I'm\r
  83 extremely uncomfortable with a build system I can't understand.\r
  84 \r
  85 Meanwhile, cairo *still* has a shell script needed just to bootstrap the\r
  86 autconf/automake/libtool house of cards, and that shell script alone is\r
  87 194 lines.\r
  88 \r
  89 So I'd very much like to continue exploring what we can do with our own\r
  90 configuration system, (in whatever language/language(s) make sense). In\r
  91 the meantime, I'm happy that I can just checkout and build notmuch on a\r
  92 Linux system with no configure step at all. I also like that the\r
  93 build-system doesn't trigger constant re-runs of configure all the\r
  94 time. I've spent too many days of my life watching autoconf output\r
  95 scroll by, and I'd really like to avoid going down that road.\r
  96 \r
  97 So yes, Jeffrey, if avoiding autoconf is the motivation, then I'm right\r
  98 there with you. But I'm not convinced that throwing out GNU make is the\r
  99 right thing to do as well.\r
 100 \r
 101 Thanks for listening,\r
 102 \r
 103 -Carl\r