Author Topic: About C::B project file...  (Read 21122 times)

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
About C::B project file...
« on: December 06, 2005, 09:22:12 am »
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)
Be patient!
This bug will be fixed soon...

takeshimiya

  • Guest
Re: About C::B project file...
« Reply #1 on: December 06, 2005, 09:30:11 am »
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?

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: About C::B project file...
« Reply #2 on: December 06, 2005, 09:54:39 am »
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 :)
Be patient!
This bug will be fixed soon...

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5490
Re: About C::B project file...
« Reply #3 on: December 06, 2005, 10:34:14 am »
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

Offline David Perfors

  • Developer
  • Lives here!
  • *****
  • Posts: 560
Re: About C::B project file...
« Reply #4 on: December 06, 2005, 10:38:35 am »
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)
OS: winXP
Compiler: mingw
IDE: Code::Blocks SVN WX: 2.8.4 Wish list: faster code completion, easier debugging, refactoring

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: About C::B project file...
« Reply #5 on: December 06, 2005, 10:48:51 am »
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.
Be patient!
This bug will be fixed soon...

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: About C::B project file...
« Reply #6 on: December 06, 2005, 04:21:33 pm »
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.)

Offline Michael

  • Lives here!
  • ****
  • Posts: 1608
Re: About C::B project file...
« Reply #7 on: December 06, 2005, 04:34:59 pm »
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

Offline Urxae

  • Regular
  • ***
  • Posts: 376
Re: About C::B project file...
« Reply #8 on: December 06, 2005, 05:36:07 pm »
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.

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: About C::B project file...
« Reply #9 on: December 06, 2005, 05:51:42 pm »
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.
Be patient!
This bug will be fixed soon...

takeshimiya

  • Guest
Re: About C::B project file...
« Reply #10 on: December 06, 2005, 06:03:25 pm »
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. :)

Offline Michael

  • Lives here!
  • ****
  • Posts: 1608
Re: About C::B project file...
« Reply #11 on: December 06, 2005, 07:33:55 pm »
... 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

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: About C::B project file...
« Reply #12 on: December 06, 2005, 07:56:26 pm »
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 ;-)

Offline Urxae

  • Regular
  • ***
  • Posts: 376
Re: About C::B project file...
« Reply #13 on: December 06, 2005, 08:03:19 pm »
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.

Offline Michael

  • Lives here!
  • ****
  • Posts: 1608
Re: About C::B project file...
« Reply #14 on: December 06, 2005, 08:15:36 pm »
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