Multi-config make?

[rickg22]

Hi all, maybe you've noticed that we have 4 makefiles now... makefile,makefile.261,makefile.unix, and makefile.unix.261.

And there's the two different projects, codeblocks and codeblocks-unix.

I think this is an unnecessary burden, as the compiler options could be modified to be set per platform, don't you think?

The problem is the how... how can we improve this makefile madness without overcomplicating the SDK? Yiannis, i know you're busy and everything, but we need your help here, as the "how-it-works" for the compiler (SDK / plugin) is rather difficult to understand...

[AkiraDev]

Any possibility of allowing the user to indicate the target platform of a specific project target?

[rickg22]

Exactly.

[zieQ]

Well, I found out that there's another problem with C::B to match the exact same functionnality of MSVC about project management, and basically, multi-config is just what's missing, so I also want it

In MSVC, we have a notion of "Build Configuration". There's a per-workspace configuration and per-project configurations. A per-project configuration is basically a set of compiler/linker switches for a  project (which is a set of files, equivalent to a target in C::B), for example, one for debug build, one for release build. You can set different -D settings and link to different libs in each configuration for example. The per-workspace configuration provides global configurations to build. In this case, the per-workspace configuration is basically the set of projects (targets) to build (maybe we don't want to build all projects for release build) and the matching of the project-config to use.

Don't know if I'm clear, so I'll take an example: quake3 project files. (Yes, you have already read about that ). Quake3 solution (workspace) is composed of 4 configs: debug, debug TA, release, release TA. The difference between debug and debug TA is that the solution is using (build) the project "ui" in the first case, and the project "q3_ui" in the second case, that is, q3_ui is not build in the first case. Think that in this case, the solution build two different games using the same engine but don't know what TA is meaning here.
The global (per-workspace) configuration should match project ones. For example, project Splines is only composed of a debug and a release config. So in the workspace file, all configurations use the project Splines, but debug config use Splines-debug config, debug TA config use also Splines-debug config, release config use Splines-release, etc.

I think that this allow the functionnality you described Rick. You set one config for windows, one config for unix, maybe some configs using different compilers, all configs using by definition the same set of files.

I already think about implementing it. A per-project configuration correspond to a CompileOptionBase, we just have to add a new function in ProjectBuildTarget to set the configurations (i.e. name string + a compile option base). Options are inherited from say, the workspace, then the project, then the target, then the config. Ouf... I didn't thought about the per-workspace config but it should not be hard to implement it too.

[zieQ]

What appear here in MSVC is the global, per-workspace configuration

[attachment deleted by admin]

[zieQ]

Oh I forgot... In each project configuration, you have a field "Platform" which is always set to Win32. Maybe we could do the same thing for projects and solution configs Rick, have a look in the screenshots for the dependency functionnality, you should see what I mean

[squizzz]

Think that in this case, the solution build two different games using the same engine but don't know what TA is meaning here.

I think its Team Arena, official expansion pack for Q3.

[mandrav]

I 've though about "configurations" too (and almost started implementing them). I 'm not sure though it's a good idea, at this stage, to make such intrusive changes. Maybe after 1.0?

Yiannis.

[zieQ]

I don't mind. Anyway, I'll patch the MSVC importers to reflect the changes as soon as this will be implemented. For now, configurations are implemented as targets, so the file lists are duplicated from config to config, no so smart but it works

[rickg22]

Maybe after RC2?  Anyway, I said the multi-config option because frankly, C::B make management is A WHOLE MESS. It's not the first time the makefiles get messed up, and well, if we're adding the dependency stuff i *HOPE* adding the multiconfig will be equally easy.

Just a warning: Before committing ANY relevant changes, we should TAG!

Actually I was thinking about releasing a beta (or "unstable snapshot") before these changes are made. I think that'll get rid of many redundant bug reports... tell you what, let's make a feature freeze and try to fix critical bugs (crashes) like the splitpanel one, and we release a binary snapshot (or RC2) for next weekend. Then we can move onto adding the multiconfig and inter-target dependencies functionality

Opinions?