On Friday 31 August 2007 22:22:44 Michael Gogins wrote: > My initial response is, I do not think it is advisable to invest time and > effort on an alternative way of doing something that already works, in a > co-operative project, unless you can show to everyone's satisfaction that > the alternative is clearly superior. Of course. However, my experience shows that new features are more rapidly incorporated if there is a preliminary patch going on. So I implemented a half-working thing before even proposing it. > > My second response is, I use not only Scons (with Csound) but also CMake > (at my day job, to build a large cross asset platform trading system) every > day. There is no doubt that CMake works well. But my distinct impression, > based on long experience with both tools, is that SCons is better, mainly > because everything is just Python code and it is easy to program and add > onto. (I also have extensive experience with plain make, with Microsoft > project files, with GNU autotools, and with Ant. I also prefer SCons to all > of them.) Heh, I kind of think using python to build a program is not a good thing (partly because I don't like python that much). The problem is that usually the configuration and building logic get mixed, which makes it more difficult to understand the code. Plus, CMake code seems to be shorter (my cmake patch consists of ~600 lines, while SConstruct is ~2100, although there is lots of stuff missing in the cmakelists). > > That SCons replaces make is by design. Make, in my experience, is not > really very good, and that is why all these other build tools have > appeared. The problem with that is that the configuration phase is lost: you have to configure it each time you build, clean or install, which gets boring quite fast (specially for csound with its 20+ options). > > SCons also allows for out of directory builds, by the way. Oh, I didn't know that. > However, in spite of experience to date, I am certainly willing to try your > CMake build system. You could email me the files and instructions. I'm attaching as a gzipped tarball only the added and changed files. > One > thing that has happened is that many people have worked on the SCons > SConstruct file, and as a result it has become rather tangled and unclear. Indeed. The main problem I see is that it is a single file describing the whole project, instead of several files each describing a section of it. > Probably I would prefer cleaning up SConstruct to switching to CMake, but > as I said I am willing to try it. Great! -- Felipe Sateler