Build system poll

#1 Which of those can be used on windows with less than 2 extra applications to install at a total of less than 100mb.

Which of those can be used on windows without some form of 'faux linux' being installed

Which of those can be used by an artist who doenst have a dozen years of systems programming experience?

#2 Which of those can be made to not screw with my existing PHP install?

#3 I like the idea of CMake, mostly because I've actually used it before*. I see some people have already started working on this on Github.

*Okay, so I've used makefiles as well... but I'd rather not go there...

#4 CMake is horrible IMO, but I've used it a lot and it works if you know what you're doing and got some patience when it decides to crash.

Personally, anything that doesn't involve installing ~20 dependencies.

#5 Maybe I'm missing something, but are we referring to something to just assemble the project files?
Doesn't the built-in php project builder already do that? What would be the advantage of having any of these as well? It just sounds like it's being an over-complicated fix to an already solved problem.

#6 Moving to an externally supported system will mean that if Torque ever becomes truly cross-platform, the work of supporting builds on those platforms is on the developers of the build tool, not on the developers of Torque. And it's likely most of that work is already done.

It also means new developers, if they choose to get involved in the build process, will learn about software and toolchains that might apply to other projects they work on rather than being Torque-specific... and there's a chance they'll already be familiar with it.

#7 To be fair, there should probably be another choice in the poll:

9 - Keep Torque 3D's current, cross-platform build system

I'll be interested to see the results of this poll. And I really hope that more than just the hard-core programmers chime in.

- Dave

#8 Personally I'm only in No9. I believe and see in practice that, if you write good C do what you want.
You only need good design and resource exploitation, believes.
6 months ago writes on T3D an MMO engine, at the moment everything is working better than expected, with very good performance in speed.

#9 For the time being I see nothing wrong with Torque's current project generator, and I use CMake on my own personal projects if it matters. ;)

#10 While I find it strange the current generator is written in PHP, I think it works fine and isn't that difficult to modify. I usually only end up running it once and simply modify the VC++/XCode projects.

The only system I really like on that list is CMake.

#11 An alternative to CMake is premake. It's OS binaries are quite small, it's getting updated regularly, and doesn't need really anything to run it (building is a bit different).

It uses Lua for project templates.

It can generate all of these:

• Microsoft Visual Studio 2002-2010, including the Express editions
• GNU Make, including Cygwin and MinGW
• Apple Xcode
• Code::Blocks
• CodeLite
• IC#Code SharpDevelop
• MonoDevelop

#12 I vote for CMake.

I looked at premake recently, but was not particularly impressed. I like the idea of having an imperative scripting language in theory, but it looks to be fairly limited feature-wise OOTB, and there doesn't seem to be an action to build XCode 4 projects, even though XC4 has been out for two and a half years already. It seems a little suspect that there is no VS2012 support yet either.

#13 All of those options are always available to everyone at all times - have at it.

Or are we talking about adding and maintaining an alternate to the current solution? The current system works and is easy to tweak. I'm having difficulty seeing a "need" for a change, though it's very easy to see a "want" in light of the myriad of tastes out there.

The thing to really put thought into here is this; Is it necessary? Or is this effort that could be better spent adding features or fixing bugs in the engine itself?

Just saying....

#14 From a committee maintenance, and work-load, perspective I'm pretty much in agreement with Richard's post...

Personally, #9 works fine for me.

#15 I'm sticking with #9 as well. I can't see any particular need or requirement to change what works as a global solution.

#16 Is it technically "necessary"? I guess not. Few things are necessary. The real question is - would it provide enough value to be worth the time and effort? I would give that an emphatic yes, particularly considering the evolving desire for new platform support.

The current system "works" and it's fairly easy to make simple "tweaks", but anything beyond that is not very easy or quick without a solid working knowledge of the structure of the project files for every version of every environment supported. Adding support for a new platform/environment could take several hours to get the project template right - time that could be spent getting the code right instead.

It also doesn't have all of the nice things that CMake has like support for packaging hooks, unit-test hooks, Continuous Integration, cross-compiling, command-line driven configuration options, and the hundreds of existing modules for supporting things like, for instance, Qt - detecting a Qt installation directory and automatically invoking moc for a set of source files only takes a few lines of code. Try adding support for that in just the 4 development environments currently supported by the Smarty template system in any robust fashion, and see how long that takes.

#17 I didn't mean to come across as arguing against the idea - just trying to provoke more in-depth commentary that would highlight cost to benefit points so that those of us who don't use CMake or <insert cool build system here> have some useful data for making an informed decision. And to find out if there is real value added for the effort involved.

In fact, Gerald has hit upon exactly what I was looking for - an informed explanation of the benefits to be gained moving to CMake. Now if we can get some input from people who have used the others on the list....

#18 I've used most of the others as well, and the only other one I would really consider from the list is SCons, but unfortunately it - like all of the rest - lacks the ability to generate project files for IDEs except for some rudimentary support for Visual Studio projects. A large part of the target audience are people that I think would not be too comfortable with a build-sequence-only solution.

#19 I vote CMake if we're going to change it, though am also fine with the current system.

#20 I agree with Gerald. It's not about necessity.

I know a lot of opposition comes to posts like this where we gripe about what the best way to do things would be, but don't put forth the effort to implement the solutions ourselves. Though in this case it sounds like Gerald's already done most of the work, which is awesome. I may have overestimated the amount of work necessary to port the thing to CMake!

Gerald: would you be averse to putting up your work in a fork on Github? I'd love to take a look at it, if it's not too much hassle.