Different compilers per target in the same project

[fabrizio.benedetti]

I just can't get this to work. I have the MinGW and the VisualC++2005 correctly configured, but I cannot create a project where one build target uses GCC and another build target uses MSVC. Either way I go, the 2nd compiler fails:

 - I create a new project with Debug + Release configurations using GCC, then I add a MSVC target. The GCC targets build fine, the MSVC target rises an exception (I reported it in the development forum: http://forums.codeblocks.org/index.php?topic=8753)

 - I create a new project with Debug + Release configuration using MSVC, then I add a GCC target. The MSVC targets build fine, the GCC target logs "Execution of mingw32-g++.exe [...] failed".

  I also tried to create the 3rd target by duplicating an existing one, or by Adding a new one - same results.

  I verified that there are no 'global' per-project compiler options, and that the targets don't append their options to the global ones (but that should give command-line errors from the compilers rather than C::B exceptions or failure messages).

  What steps do you take to create multi-compiler projects??? (Killerbot, I hope you're reading this!  :wink:)

[fabrizio.benedetti]

  I see that in a project there's a global "Selected Compiler" option, which can be seen by selecting the "Project" | "Build options..." command and then choosing the root in the Build Targets tree, on the left of the "Project build options" dialog. I found that selecting a Build Target is not enough to succesfully build: before building, I must change the "selected compiler" field in the project.

  Is this the right way to go? Is it going to be enhanced in the future? If I can associate a compiler to a Build Target, selecting that Build Target should be enough to build using the associated compiler.

[killerbot]

yes, that is correct.

Could you provide me your ?little? test project that fails. I will study it.
Not however that there are combinations of 'project' and 'target' settings. Maybe you have added a project setting and the the target uses append/prepend target settings to project settings. Then you can have issues since a setting on the project level might be compiler specific.

[fabrizio.benedetti]

Hi killerbot,

  the test projects were created by wizards, and they're working now - provided I switch the compiler in the global project settings before building. I find it's quite annoying (after switching the project compiler a dialog asks me if I want to set the new compiler in all the Build Targets!) but if that's the way it's supposed to work in the current release, then I think it's not worth your time to study them.

  Now I must find out how will I be able to manage in Code::Blocks my 'real' workspaces (currently implemented in VS6 with some hacking), where I have tens of projects, each with multiple configurations. Manually switching from one compiler to another in all the projects before building would be a little bit time-consuming and error-prone.

  Also, I have to find out if the "Build Target" combobox found on the toolbar only changes the current project's Build Target or if it sets the Build Target in every project of the workspace (provided every project has a Build Target with that name... VS6 works this way, whereas VS2005 has the Configuration Manager which maps a Solution Configuration to projects Configurations).

  Cheers!
    Fabrizio

[killerbot]

you should not have to change the compiler on the project level !!
Target is sufficient.

If so, it is a bug.

Therefor could you provide a little test project that fails on your system ?

[fabrizio.benedetti]

Here it is!

[attachment deleted by admin]

[killerbot]

I will try it out tomorrow on my windows box, but the general compiler flag, does NOT hold for GCC, it only holds for MSVC

Code

		<Compiler>
			<Add option="/W3" />
		</Compiler>

[killerbot]

everything works fine for me.

1) with MSVC as project compiler  [GCC even quietly ignored the /W3]
2) with GCC as the project compiler

[fabrizio.benedetti]

  I removed the /W3 global option, but C::B still crashes when selecting a Build Target which has a different compiler than the one selected at project level. I expected gcc ignoring the /W3 option, but my problem is GCC not being even invoked: C::B finds the Compiler object uninitialized when building the command line, so an exception is thrown; seems that only the Compiler selected at project level is Intialized. (see my topic in the development forum)

  I can perform some more debug on my machine (yes, the exception is also thrown when running the last version from SVN). Can you give me some debug hint? Where to place breakpoints, what to check, and the likes... you might even debug yourself on my machine via some remote control, if you have some time and really want to take a look at it. 

[killerbot]

we always want to solve crashes.

I would say try to create a clean CB install (!!(re)move your default.conf!!). Maybe somethings goes wrong towards MinGW GCC. I never heard of this issue.

[fabrizio.benedetti]

 

I deleted default.conf and let C::B re-create it. I didn't perform a clean install, but the crash also occurs when running the last build in the debugger, the only things in common being in the user folder

C:\Documents and settings\Dati applicazioni\<username>.<DOMAIN>\codeblocks

It's in italian, and I am in a domain so I have .<DOMAIN> appended to the username, but I hardly see how this can cause the bug which forces me to select the compiler at the proejct level or crash. In the user folder, the files I find are:

default.conf
cbKeyBinder10.ini
cbKeyBinder10.ini.bak

share\codeblocks\Plugins and share\codeblocks\scripts subfolders are empty. Another non-standard configuration is the MinGW installation path, which is in C:\Programmi\MinGW instead of the default C:\MinGW (I have to point C::B manually to this folder, auto-detect won't work). MSVC is in a path with spaces, but it is the default one (C:\Programmi\Microsoft Visual Studio 8, with no quotes...) and is auto-detected - and working, when MSVC is selected at project level!

You can have a look at the attached default.conf file, which is the one C::B re-created after I removed the previous one.

[attachment deleted by admin]

[fabrizio.benedetti]

 :mrgreen: :idea: :mrgreen: :idea: :mrgreen: :idea:

I found the cause of the bug: in my tests, I was always using the "Build file" command, instead of building the whole project. The latter works perfectly, but when building a single file C::B doesn't select the current buildtarget's compiler! CompilerGCC::SwitchCompiler() gets (indirectly) invoked by CompilerGCC::Build() and CompilerGCC::Rebuild(), but not by CompilerGCC::CompileFile(). So, if I have not yet built the whole project using another compiler than the one selected globally in the project (which happens to be initialized by the CodeCompletion plug-in on opening the Workspace), CompileFile() fails because the compiler it has to use has not been initialized yet. I even found that whien compiling a single file, Init() is invoked on one compiler, and GenerateCommandLine() on another.

[killerbot]

good to know you found the same working way as we do :-)

Please file the bug on the single file compile command. This is a bug and we should fix it.

[MortenMacFly]

This is a bug and we should fix it.

I don't think this is a bug. Compiling a single file has nothing to to with any active project/target. So in fact choosing a compiler from an active target would in 99% be an error. compiling a single file always chooses the default compiler which is good (and by design!). In the end it's for quick tests anyways and not for "serious" programming.

[killerbot]

yes, Martin is correct : no project --> no project compiler. But the inconsistency to use one, ends up in another might be interesting to have a look at.