monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Re: news and survey


From: Matthew A. Nicholson
Subject: Re: [Monotone-devel] Re: news and survey
Date: Wed, 02 Feb 2005 07:58:21 -0600
User-agent: Debian Thunderbird 1.0 (X11/20050116)

graydon hoare wrote:
Matthew A. Nicholson wrote:

Scons will configure and build cross toolchains and you can make it build native dependencies with what ever you want it to.


I think you're misunderstanding what I mean.

what I mean is that if I have a C++ file, and I'm on a linux host, and I write down the name of the C++ file in a scons script, the default scons rulebase is not going to do the following:

 - download toolchain sources from gcc.gnu.org
 - configure the toolchain for mingw cross
 - build the tool chain and install it in a scratch directory
 - download boost and popt from the net
 - build them under the mingw cross
 - build my C++ file under the mingw cross, linked against the
   built popt and boost
 - run windows under qemu, and execute any tests I have of the results

of course if I had more patience I could write scons rules to do that. I could also write automake rules to do that, or shell scripts. but the fact that I *could* write such rules doesn't make the rules exist. that process is what we need a build volunteer to do, and scons won't, by default, automate any of that for us. no tools currently will.

What do you mean by distcheck?


distcheck is a target in automake's default rulebase. it's a very useful pre-distribution rule, which does the following:

  - make a tarball of the proposed distribution
  - unpack it, configure and build it in a separate directory
  - run the tests and stop if they fail
  - make clean and make sure that eliminates all unknown files
  - report that the tarball is OK for posting to the net

distcheck catches lots of stupid pre-shipment bugs. missing files, bad include paths, extra shipped junk. scons has no such rule. it has no concepts of testsuites or packages. of course I could write these rules for scons. but that's the way scons is: its default rulebase is a bit skimpy compared to autoconf and automake. scons' chief virtues are not the rules, but the design:

 - multiple toolset support (like bjam)
 - internal dependency scanners (like bjam)
 - hash-identified product caching
 - real programming language

these are fine virtues, and I think scons is a fine program. I would like to use it. I am currently continuing with autotools because last time I tried an scons conversion, I ran out of patience with all the rules it didn't know, that I already had covered by autotools rules. it's just a matter of sloth. I didn't want to write the rules myself.

-graydon


OK see now I see. You are the first person (when I have suggested scons to any one) to give solid reasons for not using it. You mind if I forward this email to the scons people? But it's still like you said. You don't want to write all the tools, I understand. Thanks for not just trying to flame me or something. It's things like this why monotone is as good as it is.


--
Matthew A. Nicholson
Matt-land.com




reply via email to

[Prev in Thread] Current Thread [Next in Thread]