Author Topic: Support for multiple compilers/configurations per project  (Read 7935 times)

KhaoticMind

  • Guest
Support for multiple compilers/configurations per project
« on: August 09, 2005, 02:39:50 pm »
Hello there,

i just re-started using Code::Blocks last night after spending some time with Eclispe, and i must say it really evolved quite a bit since last time i checked it.
Good work :)

For me it just miss a couple of things to be "perfect". So here we go :)
I'm the kind of guy who likes making sure my code compiles both under VC++ Tolkit 2003 and Gcc (or, in fact, as many compilers as possible), but i think C::B doesn't have a good support for it yet, since the compiler options are kept per project, and not per compiler. I can see that since if i switch from gcc to vc++ in any project it tries to use compilers options from gcc, like -O0 or -g, and vice-versa. Do you guys think this could be "solved" before v1.0?

Also, is there a way to set and save different configurations per project?
For example, i want to have a configuration for debugging and another one for release, maybe with both sharing a common set of options (like warning levels).
But not limit to just these two examples i gave, allow me to set as many configurations as i want. Currently i'm using targets to do this, but i'm pretty sure this is not the best approach.

Ow yeah... i'd also love to see a mix of these suggestions, where i could have a VC++ Debug setting and a Gcc release setting for example, without one interfering with the other. That would definitely rock my world :D

Last, but not least, (i know i'm already asking too much for my first post, but i can't avoid), integrating the microsoft debugger would be GREAT :)

Thanks, and keep on the good work ;)

Cheers,
KM

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Support for multiple compilers/configurations per project
« Reply #1 on: August 09, 2005, 02:55:09 pm »
Build targets?
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

KhaoticMind

  • Guest
Re: Support for multiple compilers/configurations per project
« Reply #2 on: August 09, 2005, 03:36:29 pm »
like i said i don't think the primary objectives of targets is this
i see these targets as Makefile targets, so i can build different parts of my project and so on
confirming this is the option that says "Build target: All", what doesn't make sense if you think of it as "debug" "release" and so on...
nonetheless, i still use them like this

that is, if i understood your "question"

Cheers,
KM

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Support for multiple compilers/configurations per project
« Reply #3 on: August 09, 2005, 04:09:00 pm »
I fail to understand the actual problem. Is this not exactly what build targets are for?
Build targets allow different options (warning level, optimization, whatever) added to common settings (or, at your option, replace them), can produce different output executables, can use different compilers, and you can compile only one of them or all at once.

This:
if i switch from gcc to vc++ in any project it tries to use compilers options from gcc, like -O0 or -g, and vice-versa.
is not in concordance with my experience.

If you switch to another build target with a different compiler (I just tried with gcc and MSVC), it does very clearly use different compiler options.

Build targets seem to be quite a good solution to me. Which solution would be better?
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

KhaoticMind

  • Guest
Re: Support for multiple compilers/configurations per project
« Reply #4 on: August 09, 2005, 04:32:05 pm »
i see your points there.
Like i said, i had a different vision for build targets (thou, building all of them at the same time makes no sense for me, since the results would be overwrite by the last target).
For me, build targets would allow you to build parts of your software (like i said, like in Makefiles), so you can specify to build just the GUI, just the logical part, the framework and so on, and do a full build whenever you want (also, this is shown as well by the fact i can select which files i want to compile/link).
But yeah, if the objective of they being there is to allow different settings for the whole application i'm ok with it (like i said i was already using them that way).

About the other problem you mentioned this happens if you change the compiler inside the same build target.
For example, i've now a build target called vc-debug, that uses the VC++, if i switch to gcc (in this same target) it shows the "/Zi" option under more options, and will pass it to gcc.
But yeah, if i create one target and stick with the compiler to that target it shouldn't be a problem.

Anyways... thanks for the explanations none the less!
I was a bit "confused" at first on what is the objective of build targets, since it didn't appear quite obvious to me, since my first intention was to use it like i described above (specially thanks to the "all" option and the option to select different files).



EDIT:
Ok, just tested what you suggested, and it didn't work.
Or i'm messing something up, or C::B messed something up, or this is not the correct approach.

I've now four targets: vc-debug, vc-release, gcc-debug and gcc-release
The main compiler for the project is selected as VC++ and i try to compile the vc-debug target. When i do this it passes some gcc options to it (like -pedantic and -Wfatal-errors). And no, there is not any option left out at the options field.
The opposite also happens, if i try to compile a gcc- target it passes some VC++ specific options to it (even if i change the main compiler to gcc).

One other thing i just realized, is that right clicking the project, going under "specific build target" and them "compile", i get a list of my targets, and there is a small check box down there that says: "This target provides the project main executable" ,and it can enable for only one. So i was right, the objective of targets is to allow building different parts of the system at different times.
So, all my requests are still relevant :)

Edit2:
Not to mention compiler specific settings that are loaded per project and not per target, so, if i set the main compiler to VC++ it won't use my gcc include dirs, even if targets are configured to use gcc.


KM
« Last Edit: August 09, 2005, 04:52:54 pm by KhaoticMind »

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: Support for multiple compilers/configurations per project
« Reply #5 on: August 09, 2005, 05:43:20 pm »
We're working on redesigning the project's settings so the options can be set per target, per compiler, per project. My idea is that each target will have a set of compiler-options, and each set of compiler-options includes one for each compiler. I'm not exactly sure how this will be implemented (I need to study the code a bit more), but I'm working on it :)

It's just a matter of time... but I'm afraid it won't be ready for 1.0 :(

takeshimiya

  • Guest
Re: Support for multiple compilers/configurations per project
« Reply #6 on: August 09, 2005, 06:23:21 pm »
I think the compiler choice must be at the Project level (and maybe Workspace and Target too).

Intel Compiler let's you change back and forth between MSVC compiler at the Project level I think