#1420 Compiler detection overwrites users' configuration of built-in compilers

[Miguel Gimenez]

Reported by Eckard Klotz in this forum post.

He checked that [r13159] works while [r13166] does not work. There are only seven commits, and only the MSVC compiler detection looks related to this issue.

[Miguel Gimenez]

My guess is that adding MSVC2017 detection forces rewriting of the <sets> key in the config file, replacing the global variables with their values.

This is not fault of the MSVC2017 complier detection code, any change of any data stored in <sets> will trigger this issue.

Eckard, can you try inserting the attached XML after the </msvc10> tag in a test conf file with global variables and execute the current nightly with said config file?

[Eckard Klotz]

Hello Miguel Gimenez.

Thanks for your effort.

I tested your workaround but unfortunately without any change:
* The compiler auto detection warning is still appearing.
* My own Compiler configuration will still be overwritten.

For the case that I misunderstood your idea I have attached my extended conf-file.
* Please don't hesitate to tell me that I have implemented your patch wrongly.

Best regards,
Eckard Klotz.

[Miguel Gimenez]

The file is OK, I was trying to fool the compiler detection with a default MSVC17 to no avail.
I will work on this, but currently I have no time and the related code is a critical one.

[Eckard Klotz]

Hello Miguel Gimenez.

I will work on this,

Could there be more I could expect?

• It is clear for me that you work not only on my issue.
• Please take the time you need.

Best regards,
Eckard Klotz.

[Miguel Gimenez]

The code starting at autodetectcompilers.cpp:85 is responsible of this, the call to AutoDetectInstallationDir() replaces the user-set path with the detected one.

IMHO the code should check if directory path_no_macros exists, and only if it does not then launch autodetection.

[Miguel Gimenez]

The code for the user-defined compilers does exactly what I suggest. Can you try copying the gcc compiler, setting the global variables in the copy and using this new compiler in your project?

[Eckard Klotz]

Hello Miguel Gimenez.

Can you try copying the gcc compiler, setting the global variables in the copy and using this new compiler in your project?

I assume you ask me.

I'm a little bit unsure if I understand you right. Thus please correct me if I'm wrong.
* I have copied the compiler setting in Code::Blocs Revision 13107 (the one I use currently) and got a new compiler called "Copy of GNU GCC". The setting by using the global variables was copied automatically. Please refer the file "MinGW_12_2_0_64msvc_MSYS_Test_prepared.conf"
* Now I have started Code::Blocs Revision 13360 with the extended personality with the following results:
1. The compiler auto-detection pane appeared again (CB_13360_compilers_autodetection.png)
2. The default configuration of the GNU GCC Compiler is damaged again (CB_13360_GNU_GCC_Compiler_toolchain_executables.png).
3. The copy of the GNU GCC Compiler is still using the global variables (CB_13360_Coppy_of_GNU_GCC_Compiler_toolchain_executables.png).

I reconfigured my current hobby-project for using the "Copy of GNU GCC".
1. The complete rebuild of the binary worked without problems.
2. The resulting binary is working as expected.

After closing Code::Blocks the conf-file was modified. Please refer the file "MinGW_12_2_0_64msvc_MSYS_Test_afterClose.conf"

I hope this experiment is answering your question.
* Unfortunately I'm occupied now.
* But I hope I will available for further questions in the afternoon (Germany).

Best regards,
Eckard Klotz

[Miguel Gimenez]

1. The compiler auto-detection pane appeared again (CB_13360_compilers_autodetection.png)

This is expected, should happen only once.

1. The default configuration of the GNU GCC Compiler is damaged again

OK, expected.

1. The copy of the GNU GCC Compiler is still using the global variables

Desired result.

The complete rebuild of the binary worked without problems.

This is what we were looking for. The autodetection code is a wasps' nest, so it is better to stay away. If this workaround is OK for you I will close the ticket.

[Eckard Klotz]

Hello Miguel Gimenez.

If this workaround is OK for you I will close the ticket.

Sorry this workaround is just usable for small hobby-projects but not for bigger projects with several binaries and several developers.

• For using this work-around every single build-configuration has to be touched and this for every developer.
• I'm working in a bigger project with 30 build-results and 20 developers what means 600 build-configurations have to be modified for using this workaround.

I can understand that the compiler autodetection is a nice feature for somebody who is new in programming. But if you have created your own tool-configuration it becomes obstacle, if it is not respecting the user configuration.

If you are not able to solve the issue in detail, why don't you provide the possibility to deactivate the complete feature ? If the user has configured the tools by his own he should have the possibility to deactivate everything what may disturb this self written configuration.

You don't have to know, how the autodetection works in detail. You just need to know how it will be started. Once the user has configured to skip, it the autodetection will not be started.

Ideally you offer a possibility to skip it via command-line as well as via dialogue. The command-line would give users the chance to open older conf-files without damaging them. Once Code::Blocks will be closed it writes the skip-Configuration into the conf-file as it would be done by using a dialogue.

Best regards,
Eckard Klotz.

[Miguel Gimenez]

Fixed in [r13375].

[Eckard Klotz]

Hello Miguel Gimenez.

Thanks for your effort.
I will test it with the next nightly.

Best regards,
Eckard Klotz.

[Eckard Klotz]

Hello Miguel Gimenez.

Today I tested your fix with the nightly 13385 from November the 4th 2023.
Unfortunately I'm not able to see a difference.

Please view the attached screenshot with the compiler tool-chain dialogue:

Best regards,
Eckard Klotz.

[Miguel Gimenez]

I have just reverted [r13375].

[Miguel Gimenez]

The problem is AutoDetectInstallationDir() (in src/plugins/compilergcc/compilerMINGW.cpp) does not support macros at all.

[Miguel Gimenez]

Should be fixed by [r13388].

[Eckard Klotz]

Hello Miguel Gimenez.

Thanks for your continuing effort.
I will test it again with the next nightly.

Best regards,
Eckard Klotz.

[Eckard Klotz]

Hello Miguel Gimenez.
Today I tested your fix with the nightly 13394 from November the 12th 2023.

I think you did it:

• The compiler auto-detection dialogue shown with the first start of the new Code::Blocks release is now mentioning the Gnu GCC Compiler as detected, even it is still not present in the default directory but in the directory defined by the tool-chain configuration by using Global Variables.
• The compiler tool-chain configuration is shown as configured by me.

I will start to use this new release now for my work. In the case that I face further issues I will in form you. But I think for the moment this case could be closed.

Thanks for taking the effort.

Best regards,
Eckard Klotz.