[Top][All Lists]

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

[Monotone-devel] Re: news and survey

From: graydon hoare
Subject: [Monotone-devel] Re: news and survey
Date: Wed, 02 Feb 2005 05:11:47 -0500
User-agent: Mozilla Thunderbird 1.0 (X11/20041206)

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
 - 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.


reply via email to

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