Author Topic: Query on fixing compiler rename bug(s)  (Read 3875 times)

Offline AndrewCot

  • Almost regular
  • **
  • Posts: 241
Query on fixing compiler rename bug(s)
« on: July 10, 2021, 10:12:01 am »
When I rename compiler in the SVN 12487 and by the looks earlier releases it will result in a compiler configuration that has at least a blank masterpath setting. This can be seen if you do the following:
1) Make a copy of the "GNU GCC Compiler"
2) Rename the "Copy of GNU GCC Compiler" to say "test"
3) Close the compiler dialog
4) Exit CB
5) Load CB.
6) Select ok on the auto detect dialog.
7) Open the compilers dialog
8) Select the "test"
9) Select the "Toolchain executables" tab and the path is blank!!!

I would like to fix this while making other changes in the compilerioptionsdlg.cpp file, but there may be a number of ways to fix this and as such I would like to find out if the following would be acceptable as a fix before I start making changes, but if it not okay please let me know another way that would be acceptable that I can look at to implement:
1) Keep the exiting new name request GUI
2) Use the existing copy functionality to make a copy with the new name with the GUI name request disabled
3) Delete the old compiler name using the existing delete functionality  with the delete configuration disabled

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13438
    • Travis build status
Re: Query on fixing compiler rename bug(s)
« Reply #1 on: July 10, 2021, 10:26:18 am »
Step 6 for me doesn't happen on linux.
My version of C::B doesn't popup the auto-detect dialog and everything works as expected.
At least the compiler's installation directory is correct.

Have you debugged what is the actual problem?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline AndrewCot

  • Almost regular
  • **
  • Posts: 241
Re: Query on fixing compiler rename bug(s)
« Reply #2 on: July 11, 2021, 02:00:14 am »
I have not debugged the exact cause as to see where the problem is as I need to first go through the copy code to see what it is doing and then through the rename code to see what it is not doing or doing differently compared to the copy code in order to find the problem or process that is wrong.

I was able to reproduce the issue with the last nightly SVN 1247 on Linux Mint 20.2. Let me be a bit more explicit with the instructions as it is vital that you do make any changes that cause the dirty flag to be set or the auto-detect to be triggered:
  • Select the "GNU GCC Compiler" in the compiler settings
  • Click on the "Copy" button
  • Click on the "Ok" button to add the new compiler
  • Click on the "Ok" button for the check toolchain executables exclamation info dialog
  • Click on the "Rename" button
  • Change the name to "test"
  • Click on the "Ok" button to save and close the rename dialog
  • Click on the "Ok" button to close the compiler dialog
  • Close CB via the [X] on the top right of the app
  • Run CB again.
  • Select ok on the auto detect dialog.   (BTW try to figure out why the auto-detection is being displayed with the info shown)
  • Open the compilers dialog
  • Select the "test"
  • Select the "Toolchain executables" tab and the path is blank!!!

Attached is a an image showing the symptom of the problem with the current SVN 12487 and a local build with the ticket 1117 auto-detection dialog changes that show the real reason the auto-detection dialog is shown ("User-defined masterpath issue")

If you exit Cb before renaming the copied compiler then on next CB startup the compiler is configured as you would expect.

Offline AndrewCot

  • Almost regular
  • **
  • Posts: 241
Re: Query on fixing compiler rename bug(s)
« Reply #3 on: July 11, 2021, 04:34:47 am »
I have looked a the copy compiler code and compared it to the rename code and narrowed the problem down the the following code not being included in the rename code as the rename works correctly with the equivalent block of code added (I added a rename function on compilerfactory.cpp similar to the existing copy function):
Code
    Compiler::m_CompilerIDs.Remove(compiler->GetID());
    compiler->SetName(newName);
    compiler->m_ID = newName;
    compiler->MakeValidID();

This code is required as the compiler->m_ID was not updated in the current rename source code, which caused the settings to be saved against the old compiler->m_ID "name". When CB is restarted the new name is used to generate a "new" compiler->m_ID, which is then used to load the settings from the default.conf file, but in the case I found there will be no entries and therefore the masterpath is blank (and so are all of the other settings BTW). Ouch!!!!

Looks like the rename is either not used or if it is used then other settings are updated that cause the compiler->m_ID to be updated and therefore the renamed compiler is correctly saved in the default.conf and on a restart the auto-detect is not shown.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13438
    • Travis build status
Re: Query on fixing compiler rename bug(s)
« Reply #4 on: July 11, 2021, 08:57:15 am »
Post a patch then...
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline AndrewCot

  • Almost regular
  • **
  • Posts: 241
Re: Query on fixing compiler rename bug(s)
« Reply #5 on: July 11, 2021, 11:54:47 am »
Patch will be in ticket 1111 once I finish with the testing and the last bug/issue as per forum post https://forums.codeblocks.org/index.php/topic,24567.0.html

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13438
    • Travis build status
Re: Query on fixing compiler rename bug(s)
« Reply #6 on: July 11, 2021, 05:32:45 pm »
FYI: "Something - Number of bugs " has lower chances of getting adopted compared to "Fixing bug X"...
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]