“…we’re stuck with C++ for the foreseeable future…”

performance is important, keep an eye on the D language it is nearing “1.0″ status but is quite usable now:

http://www.digitalmars.com/d/index.htm

it compiles very fast!

In the meanwhile, I’ve also tested FastSolutionBuild had performed well: same build time as MSVC2003 for full build, and about 1 second incremental build. Unfortunately, FastSolutionBuild still has too many drawbacks for what I want:

- No command-line interface (so harder to run on a script before submitting code or in the build machine)

- No better dependency checking that VC++

- Only builds a project, not the full solution or a set of projects

- No complex dependencies (can’t have multiple executables built as part of a build–which is essential for unit tests). Then again, a lot of those drawbacks are simply part of MSVC.

All that, coupled with the fact that I had lots of problems with it in the past (maybe it’s much better now), doesn’t make me want to go out and use FastSolutionBuild as my primary build system. I can see it being useful for people building from the GUI only and having just one major project with a simple dependency chain though.

I got a copy of Visual Studio 2005 Beta 2, so I’ll give it a try this weekend. I also wanted to try Boost.Build v2 and maybe even Ant, so I might do a mini-article followup with the results.

For what I understand though, the build system was improved, but Visual C++ is still not using the underlying MSBuild. It seems we have to wait for the next release for that.

Anyway, I do find Visual C++ 2005 faster to compile with and would be interested in timings when it comes out

http://www.developer.com/net/cplus/article.php/3495506

>”Recursive Make Considered Harmful” certainly did much harm to make’s

>reputation. Specifically, that paper claims that it’s very hard to get the

>order of recursion right because using recursive make has no global project

>view. I think that’s only true if you’re dealing with self-modifying source

>code files or autogeneration of source code. If that’s not the case, I can’t

>see how the order of recursion can matter at all as long as the dependencies

>are met.

Yes, that article made me stay away from make. Instead we use — VC

If make (i.e. gnu make), in general, has no problem with recursiveness, then it certainly would be much interesting to use — instead of VC

The reasoning is interesting – could you please elaborate!?

/Tompa

Maybe I need to take a deeper look into Jam. I really want the artists to be able to add assets easily without having to learn too much about scripts. Also in the dependecy checking department, from your experience with Jam do you see it easy to check dependencies between asset files? For instance, say that you have an intermediate in XML that references another file – would it be easy to check if the referenced file was up-to-date without writing a specific rule in Jam? With Scons that problem can be solved through a custom “Scanner” that parses your files for dependencies.

Looks like I still have a lot of experimenting to do with both systems.

There’s no reason you can’t use Jam for asset builds as well. It certainly seems straightforward enough to write new rules and actions to build your assets. We’ll probably be adopting Jam for assets in my team in the new few weeks.

I’ve read this article and the one on optimizing the asset pipeline.

They are both very nice, thank you for that.

I’m considering building a pipeline that can be used by artists in a very similar way as you described and also I want to be able to do builds for different platforms through a build system. Scons seems quite nice but after running your tests it proved to be too slow. Jam, as you said, wins in the speed department. My first thought was to use Jam for source and Scons for the content, but if Jam coul d be used to build data assets easily I would be happier.