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.

[fabrizio.benedetti]

compiling a single file always chooses the default compiler which is good (and by design!).

  Currently, C::B does not choose the default compiler when compiling a single file. It chooses the default compiler and initializes it, then it chooses the compiler from current build target (possibly uninitialized) and compiles the file --> exception thrown. Is this a bug or not?

In the end it's for quick tests anyways and not for "serious" programming.

  OK, I don't practice serious programming, I'm just a paid programmer releasing commercial products. Incidentally, the beta testers testing my systems think the same about my "serious" programming  :?. Nonetheless, I'd like C::B to meet my needs, and I use "build file" commands every day. I write a bunch of code, then I want to ensure it compiles good on every compiler I target: I don't want to build all my targets for that, I just want to check those lines before I go on. My projects have thousands of source files and final link takes >5 minutes per target: I don't want to spend 20 minutes just to quick test on every compiler that fresh code in that single file!

no project --> no project compiler.

  Why no project? I am compiling 1 single file, but I have a workspace open, with many projects in it, and a build target selected, and I am compiling one of the files added to one of the projects in my open workspace.

  Cheers!
    Fabrizio

[MortenMacFly]

In the end it's for quick tests anyways and not for "serious" programming.

  OK, I don't practice serious programming, I'm just a paid programmer releasing commercial products.

You realised the quotation marks, right? There is no need to start offending. I had in mind to clarify things. If that is not needed/wanted I can just shut up.

[killerbot]

no project --> no project compiler.

  Why no project? I am compiling 1 single file, but I have a workspace open, with many projects in it, and a build target selected, and I am compiling one of the files added to one of the projects in my open workspace.

  Cheers!
    Fabrizio

Ok, that's another story then. In the single file compile command I think CB should check if the file is part ofthe active (??) project and apply that project/target's settings [project/target compiler with the project/target build options with specific options specified for the file (if any)].

[fabrizio.benedetti]

Ok, that's another story then. In the single file compile command I think CB should check if the file is part ofthe active (??) project and apply that project/target's settings [project/target compiler with the project/target build options with specific options specified for the file (if any)].

  Does it really need that check? After all, the command "Build file" is there, and seems to me that it can only be invoked on one of the files from one of the projects in the current workspace, not on a random file from the filesystem. I might be wrong, but shouldn't C::B then apply the settings of the current buildtarget for the project in which the file to be compiled is inserted?

  And please, don't forget there is a condition where an unhandled exception is thrown...

  Ciao
    Fabrizio

[matioupi]

Hello,

from my user point of view, it would be more natural that the target compiler would be selected when using the compile file command...
If other people have other needs... does it means that it should be a settable behaviour ?

Regards,

Mathieu
--
http://www.incub.net/

[fabrizio.benedetti]

it would be more natural that the target compiler would be selected when using the compile file command...

Hi,

  it's not just the target compiler which has to be selected: it's the whole build target configuration; after all, even when compiling only a single file, a compiler has to be selected, but we also need options to pass it, and an ouput folder where to place the compiled obj. All this information (and more) is in the build target settings, which should be correctly applied when compiling a single file - no differently than when compiling all the files in the project and linking them (= build). There is always a current build target selected, so it makes sense to me that it is applied both when building and when compiling a single file.

  Ciao
    fabrizio