Project manager redesign?

[thynson]

You guys should proud of that many people speak highly of Code::Blocks as it is really a good and free/open source IDE. And I also agreed with it and it's my favorite one. But currently, many large projects, no matter open source or close source, free or commercial, Code::Blocks is seldom used(except Code::Blocks itself). Despite the cases of commercial projects, I think the key that why so many free software projects choose Makefile other than any other IDE is:
        1. For a free software, customizability is very important, but many IDE(Code::Blocks included) is difficult to deal with it.
        2. Free software is usually distributed in source code, however, it is not smart to make the source code itself depends on an IDE. Actually a Makefile with some shell script is enough.

The customizability is reflected in that many open source project have many build option. Currently the project manager in Code::Blocks is similar to VS. One project may have several build targets. But sometime we want our project have several build option, for example, static/shared, ansi/unicode, we will have to add static-ansi, static-unicode, shared-ansi and shared-unicode these four build target to our project. But actually we just need two options, that is, static or shared, ansi or unicode, and for each option we could have more than two choice. So that a OPTION-ORIENTED project manager other than a TARGET-ORIENTED one is needed for a IDE to improve customizability of projects. For example, a project could have several option, just like we build a software from source code, we may specify many build option in configure script. Each option may define a macro for testing if itself is enabled, turn on/off some compiler option(e.g., -g for debug build, -O2 for release build), and even change the name of output binary.
And we also need a way to generate Makefile. I recommend CMake. Autotools always test some very very basic routine such as strcmp and do many unnecessary things. Directly generate Makefile may lose chance to check dependency.

I don't think my idea is very fresh, maybe someone said something similar here in Code::Blocks forums some months ago. The change may be difficult and take very a long time. I don't expect it could come in few days, but I advise you to make it one of the long-term goals of Code::Blocks. Or if you're just doing it now, I will be happy to know it.

[oBFusCATed]

Off: Do you know that you can use a Makefile to build your project?

[thynson]

I know we can, but writing a Makefile sometime difficult to manager; when add/delete a file, we have to change the Makefile. An IDE should help programmers to manager their project well.

[MortenMacFly]

I know we can, but writing a Makefile sometime difficult to manager; when add/delete a file, we have to change the Makefile. An IDE should help programmers to manager their project well.

Are you aware that for what you describe we three very powerful concepts:
1.) scripatble (!) compiler/linker options
2.) the concept of global variables
3.) scriptable pre- and post-build steps

I believe what you want to do is already possible and would not require a "re-design". Please make yourself familiar with how these concepts work (the C::B documentation/WiKi is a good starter) and tell what's still missing afterwards.

[thynson]

Are you aware that for what you describe we three very powerful concepts:

1.) scripatble (!) compiler/linker options

2.) the concept of global variables

3.) scriptable pre- and post-build steps



I believe what you want to do is already possible and would not require a "re-design". Please make yourself familiar with how these concepts work (the C::B documentation/WiKi is a good starter) and tell what's still missing afterwards.

OK, I admit that I underestimated the build system of C::B. Actually when I say project manager there I mean build target manager.(So maybe you misunderstand what I say.).

I take wx for example, as I believe all of you have compiled wx for once or more. When we build wx in windows CMD, we use the pre-generated Makefile. the Makefile support ANSI or UNICODE, SHARED or STATIC, DEBUG or RELEASE and many other options, if we build a large library with C::B we have to set those build target: 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.
So first we should solve problem that if some one need many many options in his project. The build-target manager can be like this: if my library need to deal with both the situation when charset is ANSI, UNICODE or UTF-8, I could add "Charset" in the option list; and I want a static version and a shared version. I could add "Enable shared" to the option list. When I build my library, for example, I set the build-target to "Charset=UTF-8 Enable Shared = true".

[MortenMacFly]

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.

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]

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.

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]

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.

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