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

[takeshimiya]

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

Great!

Rick, have you considered taking a look about these C++ parsers?:

Synopsis
Developed for the Synopsis autodoc generation app.

Elsa
Elsa can parse most C++ "in the wild". It has been tested with some notable large programs, including Mozilla, Qt, ACE, and itself.

ANTLR C++/CodeStore
Modified a little this open-source multi-platform IDE: VCFBuilder.
ANTLR is one of the most popular and well know parser generators out there.

Assist++
Developed for this another open-source cross-platform IDE: Ultimate++.


And these C/C++ pre-processor parsers:
ucpp
Wave

@Michael: try TortoiseCVS, you'll don't be dissapointed.

[Urxae]

I would prefer not to install other version control systems (just to prevent conflicts).

There shouldn't be any conflict at all between CVS and SVN.
I seem to remember there being a remark on the subversion site about even being able to put the same folder in both CVS and SVN and it should work fine as long as "CVS" was in svn::ignore and ".svn" in .cvsignore. Followed by the remark they couldn't think of any reason why anyone would want to do that, though .
The only "conflict" I know of is both TortoiseCVS and TortoiseSVN on the same machine: they'd use too much shell icons (Windows has a max of 15 total, 4 of which it uses itself) if TSVN would use its full complement, so it cuts back in this situation.

[Michael]

There shouldn't be any conflict at all between CVS and SVN.
I seem to remember there being a remark on the subversion site about even being able to put the same folder in both CVS and SVN and it should work fine as long as "CVS" was in svn::ignore and ".svn" in .cvsignore. Followed by the remark they couldn't think of any reason why anyone would want to do that, though .
The only "conflict" I know of is both TortoiseCVS and TortoiseSVN on the same machine: they'd use too much shell icons (Windows has a max of 15 total, 4 of which it uses itself) if TSVN would use its full complement, so it cuts back in this situation.

Ok, then. I will give it a try. Thank you very much Urxae and Takeshi Miya.

Michael

[tiwag]

I've installed ntCVS, WinCVS, TortoiseCVS, SVN and TortoiseSVN in parallel on several machines using WindowsXP and didn't have any problems. We are in the same situation as Michael described, in the company we're using CVS (doesn't  matter which client WinCVS or TortoiseCVS) and with CodeBlocks i started with SVN and TortoiseSVN. often i use the TortoiseSVN to get information of modified files, for updating i'm using the svn-client callled from batch-files (as i did with ntcvs-client) because i manage the update-logfiles automatically.

First i was suspicious if all programs for CVS and SVN are working in parallel without unwanted interaction, but after using it now a few weeks, i can say it just works !

[Michael]

First i was suspicious if all programs for CVS and SVN are working in parallel without unwanted interaction, but after using it now a few weeks, i can say it just works !

That's good to know. Thanks. I am may be too much cautious, but one time WinCVS stopped to work. Each time, I started it, after closing the "tip of the day" window, it automatically quit. And even unistall followed by a re-install did not solve anything.

Michael

[David Perfors]

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

Another advantage of this method is that it is easier to compile with diffrent compilers. Just make some targets for each compiler

[thomas]

With inter-project dependencies, that might be an improvement, without it would be a nightmare.