Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development

Multi-config make?

(1/2) > >>

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 :D ). 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]

Navigation

[0] Message Index

[#] Next page