Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Project manager redesign?

<< < (2/2)

MortenMacFly:

--- Quote from: thynson on August 02, 2010, 04:31:49 pm ---ANSI-SHARED-DEBUG, ANSI-SHARED-RELEASE....totally is 2*2*2=8 targets. And the dropbox for the build target will become longer and longer.

--- End quote ---
Trust me: You can do this with way less targets by specifying the configuration options via attached scripts and/or variables (which might get expanded to something useful, if needed). In fact I would assume that even one target is enough.

Have a look at the C::B project for example: That we are using a monolitic, unicode etc. build is setup by variables (that expand e.g. to "u" as extension for the libraries name in the case of a unicode build).

Using scripts you can even query the platform and have the target automatically choose the right "thing" for the platform C::B runs on. Have a look at what the wizard generates for a plain common wxwidgets project. Inspect the options and search for:
[[if (PLATFORM == PLATFORM_MSW && (GetCompilerFactory().GetCompilerVersionString(_T("gcc")) >= _T("4.0.0"))) print(_T("-Wno-attributes"));]]
This uses scripting to add a specific parameter only needed under Windows and using GCC compiler revision >= 4.0.0.

Try to understand (look into the documentation) and you'll be able to do what you want.

ptDev:
Regarding the "makefile" issue, maybe a command-line tool (a "cb-make") could be made available to compile source code directly from Code::Blocks project files, without loading the entire Code::Blocks application (AFAIK, the batch build functionality still requires C::B itself to be loaded). That would make life easier for anyone trying to compile Code::Blocks itself for the first time, not to mention speeding up automated build processes.

oBFusCATed:
ptDev: As stated many times this is very hard to do because the current build system is coupled too much with wx gui classes. And I've seen no effort to uncoupling them, unfortunately.
But in my opinion the world doesn't need another autotools/cmake/scons/qmake and so on. A better project would be a framework that can make implementation of export to another build system easy.

MortenMacFly:

--- Quote from: oBFusCATed on August 02, 2010, 08:39:39 pm ---But in my opinion the world doesn't need another autotools/cmake/scons/qmake and so on. A better project would be a framework that can make implementation of export to another build system easy.

--- End quote ---
True. A first step would be to re-active the Makefile generator. Either from within the (commented) C::B sources, the cbMakefile plugin or both.

Taking into considerations other build systems from the beginning would make it probably easy to extend the code to another build system then easily.

However - keep in mind that there are really complicated things not possible using e.g. a Makefile like things you can do with scripting.

thynson:

--- Quote ---Trust me: You can do this with way less targets by specifying the configuration options via attached scripts and/or variables (which might get expanded to something useful, if needed). In fact I would assume that even one target is enough.

--- End quote ---
:)I begin to agree by do it like this way. I just realize global variables can do anything but not only locate a library.
So I just wish some command-line builder will come one day, no matter so called "cb-make", or any another make system.

Navigation

[0] Message Index

[*] Previous page