This MSDN page lists some (but strangly, not all) of the command line options:

http://msdn2.microsoft.com/en-us/library/cz553aa1

http://freshmeat.net/articles/view/1702/

http://freshmeat.net/articles/view/1715/

Hey, you’re talking only about performance. I don’t think it’s the only important factor when choosing a build system.

While SCons might be slower, it might still save you a lot of time :

- You don’t have to write complexe makefiles, but instead can write much more simple SCons scripts.

- You don’t waste time on a not-working build because some file was not recompiled while it should have been

SCons does a lot more than a simple Makefile. If use an external tools to add features like automatic implicit dependencies to you makefile, I’m not sure SCons is much more slower.

You might be interested in checking out the following url:

http://www.martinfowler.com/articles/rake.html

When I said that about Make, I was thinking of a fairly clean division along the lines of just building the executable with Make, and leaving any other tasks such as zipping it up, creating install programs, copying it over the network, checking it/out of version control, etc in Nant. The Nant script would of course call the Make as part of its work.

I would see the Nant script being used primarely in the build server, and maybe by individual developers in the rare case they need to do some of those tasks by hand.

I am planning a build system upgrade for my team.

I did not get the following statement:

“You’ll probably want to wrap Make in a more comprehensive build system (such as Ant) for your build server, packaging builds, etc. ”

Are you describing a design where you have 2 different build systems operating on the same code base?

How would you design such a system without a too high maintenance cost?

How would you teach your developers (let say a team of 10) to modify the source tree organization (add files, directories, etc) and keep the two systems in sync?

Okay, enough with the questions Thanks for the great work!

I’d like to see your SCons results using timestamps rather than md5 hashes for the files. I suspect that would bring SCons times down a fair amount.

Cheers,

Barry.

[1] making dependencies fast

[2] using the best available dev environment for a given platform.

I’ll talk about [2] first.

I used to believe that the best idea for cross-platform development was to create some sort of master build script that kicked out builds for all of your various platforms.

Then the company I work at did just that. It was a nightmare to get up and running. It is mostly working now, but it is STILL under active development. It went from a small little side project to a very large ongoing project for this poor guy.

It would be awesome if it just worked, but there always ends up being little exceptions here an there. Soon your master build file ends up being a complex monster.

Here is what I currently believe:

You have platform specific code, so have platform specific builds!!

Yes it is more work to create and maintain a build for each platform, but as long as you follow two rules, it really is not bad.

1. No dead files allowed.

2. Platform specific code goes in its own directory.

The idea is basically to use a script for each build that generates the build using wildcards.

There are details along with a vc7 generator script in my blog. I’ve since created a more elaborate vc71 script, if you want it, mail me.

http://projectjanel.org/b2e_blogs/index.php?blog=2&title=cross_platform_build_systems&more=1&c=1&tb=1&pb=1

Back to [1]. Nothing I’ve said goes against it. You just make the choice of the best dev environment for each and every platform. So if you want to have a vc6 AND vc7 builds for win32 because one of your guys refuses to switch, fine. If you want to use gnu make on linux because it works well there, fine.

The main idea is just not to try and shove all those builds into a single magic build. All that ends up giving you is the lowest common denominator.

Nice blog talking about build system