Project Manager wars

Expanding and utilizing the engine via C++.
5 posts Page 1 of 1
JeffR
Steering Committee
Steering Committee
Posts: 813
Joined: Tue Feb 03, 2015 9:49 pm
 
by JeffR » Mon Aug 10, 2015 5:52 pm
So currently, there are 2 methods to generate the engine projects for T3D.

You have the Project Manager/Generator, which works on windows, and has a nice little gui interface to manage all your projects and generate/modify the engine project files.

And CMake, which works on both linux and windows. It's a bit flakier, but generates pretty much everything ever made.

As Dan had touched on slightly in the 3.7 release blog, we're looking towards reworking how projects are managed, and so we need to figure out which backend is preferred/used when people are setting up their projects.

The ideal, in the end, is you would grab JUST the Project Manager, and it would download and generate the source, engine projects, and templates so that you don't have to juggle around as much to get cracking. However, to start with, we need to know what engine project generator people use so we can utilize it as the backbone.

So which do you guys use when setting up torque? Heck, if you have a perferred project generator that you use for other projects, feel free to chime in on that as well.

We want a robust, cross-platform generator so we don't have to fiddle with IT so much as just work on the pretty front-end GUI to make it easier and less painful to work with T3D.

(For what it's worth, I prefer the Project Manager ;) )
Azaezel
Posts: 395
Joined: Tue Feb 03, 2015 9:50 pm
 
by Azaezel » Mon Aug 10, 2015 6:59 pm
I'm generally an equal opportunity hater there.

Pro side for cmake is it does already ship with unix derivatives, so that's 1/3rd of folks that won't have to download a second project just to get moving.
Con side, it's bloody cmake.

For cmake, the configuration system is generally fairly dense so folks coming in from outside needing to add options will probably have to dig around and learn the macros. For the project manager, there is no probably since it's a non-standard implementation. They *will* have to dig around and learn the macros.
andrewmac
Posts: 295
Joined: Tue Feb 03, 2015 9:45 pm
 
by andrewmac » Mon Aug 10, 2015 7:11 pm
I use GENiE for Torque 6, which is a fork of premake by the author of bgfx:
https://github.com/bkaradzic/genie

I have no complaints about it. Took me about a day to get everything situated and I haven't looked back or had any trouble since. Works great for windows and linux, I haven't tested it on mac yet though.

I personally despise cmake.
Duion
Posts: 966
Joined: Sun Feb 08, 2015 1:51 am
 
by Duion » Mon Aug 10, 2015 7:11 pm
I prefer cmake, I somehow found it easier, even as a noob.
The project manager basically copies a template for you and generates project files, so you can copy it by hand also and generating the project with cmake is also easy, just point him to where the code is and done. The only drawback would be all the configurations, but when you are serious with game design, you have to dig through them anyway.
The project manager basically would need support, so another one who has to voluntarily work on it to improve it and keep it up to date just for comfort reasons.
buckmaster
Steering Committee
Steering Committee
Posts: 321
Joined: Thu Feb 05, 2015 1:02 am
by buckmaster » Tue Aug 11, 2015 2:44 am
The reason for using CMake was that it supports basically any build system you care to use, and it's a large popular project, which means we benefit from its documentation, developers, etc., and don't have to maintain that stuff ourselves. On the other hand, its macro language is abominable. Which is why I was suggesting trying to create some sort of nicer interface on top of that, similar to the current project manager, so developers have to deal with that as little as possible.

My next biggest motivation for replacing the current project manager is to rewrite it as a Torque application rather than Qt. Because a) dogfooding, b) better support for all the platforms Torque runs on, c) not splitting the codebase.

My final and largest motivation to redo the project manager was to start to support more features for devs. The biggest one, for me, was being able to pull in script packages instead of just entire templates. I really, really want to eliminate the duplicated scripts in our repo :p, but even more than that, I want to introduce some standard way to add content packs (and script libraries, and even source mods, etc.) to your project, so we can stop dumping everything cool people make into the templates or the main engine.

As for what I use - if I'm on Windows I'll always use the PM, unless I'm specifically trying to test something CMake-related. Takes fewer clicks to spin up a new project. The project generator has the advantage of being Torque-specific so we can tailor the generated files to Torque. The downside is obviously we have to write those files ourselves and keep them up-to-date, and I know I'm sure as hell not up for that.

The other benefit to the project generator is that the config is kept in your project. With CMake, you essentially have to run the same command-line command every time (for example if someone else pulls down your project and wants to compile it with the same modules/flags/etc.). That's something I'd want to fix with the new project manager - providing some Torque-specific config (like what modules are enabled) that tells CMake what to install. The PG does this already... by using PHP scripts. I'd recommend using XML or JSON files to manage this config instead.

Okay so TLDR: my opinion is we should ditch the PG (in the long run) and use CMake as the backend of a new PM frontend tool. We should obviously support both for a while, because our CMake files still aren't feature complete.
5 posts Page 1 of 1

Who is online

Users browsing this forum: No registered users and 2 guests