About C::B project file...

[mandrav]

The codeblocks.cbp file is currently like a makefile: it contains a separate target for each module and builds all of the core C::B.
This is one way to use.
We could use another way though:
We could create a separate project for each module. Basically make each target contained in codeblocks.cbp a separate project and wrap all projects in a workspace.
We could configure the new projects' targets (configurations) like this:

• Unicode WX DLL - Debug
  
• Unicode WX DLL - Release
  
• Unicode WX DLL - Profile
  
• Ansi WX DLL - Debug
  
• Ansi WX DLL - Release
  
• Ansi WX DLL - Profile
  

So, if anyone wanted to work only on a specific plugin, he/she could open the plugin's project and work on it. No extra burden. And choose which wx DLL to use (unicode/ansi).
Or if a developer wanted to profile the code-completion plugin, he/she could enable profiling only for this plugin (actually profiling must only be enabled for one module or else gmon.out gets overwritten).

So, what do you think? Should we make those changes or should we leave it as it is now?
(now that I think of it, we could have both ways)

[takeshimiya]

Well, it isn't the way MSVC uses?

Having projects each with one target, and configurations (ie. Release and Debug). And having all those projects inside a Workspace.

But I fear, it is that possible without inter-project dependencies?

[mandrav]

Well, it isn't the way MSVC uses?

Yes, it is. People are used to this way, whether we like it or not.

But I fear, it is that possible without inter-project dependencies?

Well, the only form of inter-project dependencies available currently is the order of the projects in the workspace (builds top-to-bottom). So a simple "Build workspace" can build it since we don't have special dependencies currently.

I have no problem with the way it is now. I just want to get other people views

[killerbot]

I am in favor of MSVC style. Woops, a pro windows comment.  :oops:
Locality and hiding of information, modular approach.
Each module has it own cbp file, there's no need when working on a certain plug-in you need to see the stuf from other plug-ins, core code, etc .. (As a side -effect no neet to parse all that other data also for eg code completion).
Makes it easy to create a special build for that 1 module (eg : special logging, profiling, ...).

Probably it's like the coding style, 1 function does only 1 thing. Plug-in X cbp does the build stuff for X and not for Y.

Adds off course dependency problem of projects.

Lieven

[David Perfors]

I don't have problems with the way it is now, but I think it is an improvement to give ALL plugins a sepperate projectfile and a workspace to include Code::Blocks main app and plugins. By doing this it already is easier to work on a specific plugin.

isn't there a possibility to give targets targets? so you have:

• sdk


• Unicode WX DLL - Debug
• Unicode WX DLL - Release
• Unicode WX DLL - Profile
• Ansi WX DLL - Debug
• Ansi WX DLL - Release
• Ansi WX DLL - Profile
• src
• etc.

Because I also like the idea to make diffrent builts (debug / release, ansi / unicode)

[mandrav]

isn't there a possibility to give targets targets?

No, there isn't.
You see, targets have the meaning you want them to have. If you 're a unix user, they 're like makefile targets. If you 're a windows user (used to MSVC) they 're like configurations.

[rickg22]

Um, I don't think i understand very well. I just want to know if I can rebuild the whole project without having to compile configurations I don't like...

If so, I won't have any problem with it.

oh btw. Is the "current target" now stored in a separate file? (Because i'm getting tired of saying "no, don't save the project" everytime i quit C::B after changing the current target in the menu.)

[Michael]

I also prefer a MSVC approach. If the project file of one module get corrupted or no more usable (for one reason or another), this would be bad, but not so bad as if the unique project file get corrupted or "out of service".

Michael

[Urxae]

If the project file of one module get corrupted [...]

... then you pull the last uncorrupted version out of your version control system. You do use a version control system, don't you?
Same for the "unique project file", of course.

[mandrav]

Um, I don't think i understand very well. I just want to know if I can rebuild the whole project without having to compile configurations I don't like...

If so, I won't have any problem with it.

You select and build only one of the available configurations. That's the main difference.

oh btw. Is the "current target" now stored in a separate file? (Because i'm getting tired of saying "no, don't save the project" everytime i quit C::B after changing the current target in the menu.)

Yes, it is.

[takeshimiya]

I personaly:

-Don't have any problems the way it is now.
-But I would like to use the more modular approach of MSVC.

However, it would requiere:
-Full inter-project dependencies
-CodeCompletion plugin capable of parsing all files outside the project.

Without those two things solved first, I would stick the way it is, for now.

[Michael]

... then you pull the last uncorrupted version out of your version control system. You do use a version control system, don't you?
Same for the "unique project file", of course.

Ehm, not really . I use a version control system only when I have to do. Until now I have only had problems with CVS command line, WinCVS, and so on. May be SVN is better.

Michael

[rickg22]

However, it would requiere:
...
-CodeCompletion plugin capable of parsing all files outside the project.

Without those two things solved first, I would stick the way it is, for now.

About that one: I'm working on an N-ary search tree which will allow adding and searching of tokens instantly, and it'll support fast prefix search for codecompletion (i.e. search for all tokens starting with a prefix). I expect the improved parser to the analyse the code 100 times faster than now. Stay tuned ;-)

[Urxae]

Until now I have only had problems with CVS command line, WinCVS, and so on. May be SVN is better.

TortoiseCVS worked for me. SVN is a lot better than CVS though. I recommend TortoiseSVN if you're on Windows (which I would guess you to be if you tried WinCVS ). The commandline svn client isn't bad either, but not as handy for day-to-day work as Tortoise.

[Michael]

Until now I have only had problems with CVS command line, WinCVS, and so on. May be SVN is better.

TortoiseCVS worked for me. SVN is a lot better than CVS though. I recommend TortoiseSVN if you're on Windows (which I would guess you to be if you tried WinCVS ). The commandline svn client isn't bad either, but not as handy for day-to-day work as Tortoise.

Thank you for the advice. I would gladly try, but the problem is that actually I am working on a big project (but we still use MS Visual Studio C++ 6 :roll:) and WinCVS is the chosen tool for version control. As I have experienced several problems with WinCVS in the past (and I need it) , I would prefer not to install other version control systems (just to prevent conflicts).
May be I will give a try with the computer of my parents during the Christmas's vacation .

Michael