Different compiler's paths are mixed together

[zetab]

I have 2 compilers setup in CodeBlocks, one is default "GNU GCC Compiler", another is "GNU GCC TDM-32 Compiler".

When I created a C console application project using "GNU GCC TDM-32 Compiler", added "echo %PATH%" command to pre-build step and build the project, I saw both compiler's toolchain path were both added to the PATH environment variable.

Is this behavior correct for CodeBlocks?

I'm using nightly build r13107 on win7 64bit.

[BlueHazzard]

I have tested this on my local machine and can not reproduce it...
Are you sure they are not in your PATH variable and not added by codeblocks?
Are you sure that the project compiler and target compiler are the same and you are not mixing both compiler in the same project? (Check in the build options on the left when you select the project name and the different target names, that always the same compiler is selected)

[zetab]

The compiler's path were added by codeblocks, not in my PATH variable.

Here is the PATH variable from cmd prompt outside codeblocks:

Code

D:\DevTools\CB_20221210_rev13107_win64>echo %PATH%
C:\Program Files\ImageMagick-7.0.9-Q16;C:\Program Files (x86)\Intel\iCLS Client\
;C:\Program Files\Intel\iCLS Client\;C:\Windows\system32;C:\Windows;C:\Windows\S
ystem32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program Files\Intel\
Intel(R) Management Engine Components\DAL;C:\Program Files\Intel\Intel(R) Manage
ment Engine Components\IPT;C:\Program Files (x86)\Intel\Intel(R) Management Engi
ne Components\DAL;C:\Program Files (x86)\Intel\Intel(R) Management Engine Compon
ents\IPT;C:\Program Files\Microsoft SQL Server\110\Tools\Binn\;C:\Program Files
(x86)\Microsoft SDKs\TypeScript\1.0\;C:\Program Files\Microsoft SQL Server\120\T
ools\Binn\;C:\Program Files\CMake\bin;C:\Program Files (x86)\Bakefile;C:\Program
 Files\NASM;C:\Program Files\TortoiseGit\bin;C:\Program Files (x86)\AOMEI\AOMEI
Backupper 6.9.2;C:\Program Files\TortoiseSVN\bin;C:\Program Files (x86)\CVSNT\

This is build log when I build the test project in codeblocks:

Code

-------------- Build: Debug in test_path_tdm_gcc (compiler: GNU GCC TDM-32 Compiler)---------------

Running target pre-build steps
echo D:\DevTools\tdm-gcc-4.7.1\bin;D:\DevTools\tdm-gcc-4.7.1;D:\DevTools\mingw-w64-i686-12.2.0\mingw32\bin;D:\DevTools\mingw-w64-i686-12.2.0\mingw32;C:\Program Files\ImageMagick-7.0.9-Q16;C:\Program Files (x86)\Intel\iCLS Client;C:\Program Files\Intel\iCLS Client;C:\Windows\System32;C:\Windows;C:\Windows\System32\wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Program Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files\Microsoft SQL Server\110\Tools\Binn;C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.0;C:\Program Files\Microsoft SQL Server\120\Tools\Binn;C:\Program Files\CMake\bin;C:\Program Files (x86)\Bakefile;C:\Program Files\NASM;C:\Program Files\TortoiseGit\bin;C:\Program Files (x86)\AOMEI\AOMEI Backupper 6.9.2;C:\Program Files\TortoiseSVN\bin;C:\Program Files (x86)\CVSNT
Execution of 'echo D:\DevTools\tdm-gcc-4.7.1\bin;D:\DevTools\tdm-gcc-4.7.1;D:\DevTools\mingw-w64-i686-12.2.0\mingw32\bin;D:\DevTools\mingw-w64-i686-12.2.0\mingw32;C:\Program Files\ImageMagick-7.0.9-Q16;C:\Program Files (x86)\Intel\iCLS Client;C:\Program Files\Intel\iCLS Client;C:\Windows\System32;C:\Windows;C:\Windows\System32\wbem;C:\Windows\System32\WindowsPowerShell\v1.0;C:\Program Files\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\IPT;C:\Program Files\Microsoft SQL Server\110\Tools\Binn;C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.0;C:\Program Files\Microsoft SQL Server\120\Tools\Binn;C:\Program Files\CMake\bin;C:\Program Files (x86)\Bakefile;C:\Program Files\NASM;C:\Program Files\TortoiseGit\bin;C:\Program Files (x86)\AOMEI\AOMEI Backupper 6.9.2;C:\Program Files\TortoiseSVN\bin;C:\Program Files (x86)\CVSNT' in 'D:\_temp\test_path_tdm_gcc' failed.

"D:\DevTools\tdm-gcc-4.7.1" is the toolchain path of "GNU GCC TDM-32 Compiler".
"D:\DevTools\mingw-w64-i686-12.2.0\mingw32" is the toolchain path of "GNU GCC Compiler".

Another issue in the above build log is the execution of "echo %PATH%" cmd were failed. If I directly input the whole expanded echo cmd to cmd prompt, there's no error.

The project compiler and target compiler are the same. The project was created by project wizard, I only added the "echo %PATH%" cmd to pre-build step.

The attachment is my test project.

[zetab]

I've tested this issue on my another win10 machine, and saw the same behavior.

[BlueHazzard]

Thank you for reporting... Could you share your configuration file (found in %APPDATA%/Codeblocks/default.conf) and a minimal project file?

[zetab]

Here is the default.conf.
For the minimal project file, you could use the test project in my earlier post.

[BlueHazzard]

Ok, i can reproduce this now...

I will look into it, but in theory it should not be a problem (beside, at least from my point of view, it is obvious a error in codeblocks) , because the current compiler is at the front of path, so it should always take this path first and so if there are clashes about naming it should always pick the right one.

Are you experiencing problems with this?

[BlueHazzard]

Well i know what the problem is...
If a compiler is changes we get the current path variable and make some modifications and then pre append our compiler path at the front.
So now if you load a project the current active target compiler gets pre appended to path, if you activate a other project we get the current path (with the compiler added from the last target) and add our current active compiler, this results in a %PATH% with the last two target compiler paths, and so on and so on. The path will grow every time you change compiler...

The simplest solution might be to get the base PATH at the start of codeblocks and then always use this base PATH and modify it on target/compiler changes as base path. This is a deep change in the behaviour of codeblocks and i do not want to decide this alone. @Other devs: any opinion?

The big question is what happens with the environment variables plugin. How does this play in here... Should it be allowed to modify path in the first place? @MortenMacFly can you enlighten me here a bit?

[BlueHazzard]

My proposal for a fix:

Code

diff --git a/src/include/manager.h b/src/include/manager.h
index 3898ecb4a..2fd9e1be6 100644
--- a/src/include/manager.h
+++ b/src/include/manager.h
@@ -158,6 +158,9 @@ public:
     /// @return The scale factor of the specified UI component.
     double GetUIScaleFactor(UIComponent component) const;

+    wxString GetOriginPath() const;
+    void SetOriginPath(const wxString& path);
+
     static wxCmdLineParser* GetCmdLineParser();

     // event sinks
@@ -181,6 +184,8 @@ private:
     static wxCmdLineParser m_CmdLineParser;
     static wxToolBarAddOnXmlHandler *m_ToolbarHandler;

+    wxString        m_originPath;
+
     int m_ImageSizes[UIComponent::Last];
     double m_UIScaleFactor[UIComponent::Last];

diff --git a/src/plugins/compilergcc/compilergcc.cpp b/src/plugins/compilergcc/compilergcc.cpp
index 6e219d2f5..af94e6ed3 100644
--- a/src/plugins/compilergcc/compilergcc.cpp
+++ b/src/plugins/compilergcc/compilergcc.cpp
@@ -23,6 +23,7 @@
     #include <wx/ffile.h>
     #include <wx/utils.h>

+
     #include "prep.h"
     #include "manager.h"
     #include "sdk_events.h"
@@ -43,6 +44,7 @@

 #include <wx/uri.h>
 #include <wx/xml/xml.h>
+#include <wx/tokenzr.h>

 #include "annoyingdialog.h"
 #include "debuggermanager.h"
@@ -759,8 +761,8 @@ void CompilerGCC::SetupEnvironment()
     if (!compiler)
         return;

-    wxString currentPath;
-    if ( !wxGetEnv(_T("PATH"), &currentPath) )
+    wxString currentPath = Manager::Get()->GetOriginPath();
+    if ( currentPath.IsEmpty() )
     {
         InfoWindow::Display(_("Environment error"),
                             _("Could not read the PATH environment variable!\n"
@@ -771,8 +773,8 @@ void CompilerGCC::SetupEnvironment()
         return;
     }

-//    Manager::Get()->GetLogManager()->DebugLogError(_T("PATH environment:"));
-//    Manager::Get()->GetLogManager()->DebugLogError(currentPath);
+    Manager::Get()->GetLogManager()->DebugLogError(_T("PATH environment:"));
+    Manager::Get()->GetLogManager()->DebugLogError(currentPath);

     const wxString pathApp  = platform::windows ? _T(";") : _T(":");
     const wxString pathSep  = wxFileName::GetPathSeparator(); // "\" or "/"
@@ -824,7 +826,8 @@ void CompilerGCC::SetupEnvironment()
     // [3] Append what has already been in the PATH envvar...
     // If we do it this way, paths are automatically normalized and doubles are removed
     wxPathList pathArray;
-    pathArray.AddEnvList(_T("PATH"));
+    //pathArray.AddEnvList(_T("PATH"));
+    pathArray.Add( wxStringTokenize(currentPath, pathApp));
     pathList.Add(pathArray);

     // Try to locate the path to the C compiler:
diff --git a/src/sdk/manager.cpp b/src/sdk/manager.cpp
index fc6ab0858..855f130f3 100644
--- a/src/sdk/manager.cpp
+++ b/src/sdk/manager.cpp
@@ -348,6 +348,16 @@ bool Manager::IsAppStartedUp()
     return m_AppStartedUp;
 }

+wxString Manager::GetOriginPath() const
+{
+    return m_originPath;
+}
+
+void Manager::SetOriginPath(const wxString& path)
+{
+    m_originPath = path;
+}
+
 void Manager::LoadXRC(wxString relpath)
 {
     LoadResource(relpath);
diff --git a/src/src/app.cpp b/src/src/app.cpp
index 9bb04d1cd..9bcdcb2d7 100644
--- a/src/src/app.cpp
+++ b/src/src/app.cpp
@@ -622,6 +622,10 @@ bool CodeBlocksApp::OnInit()
     wxInitAllImageHandlers();
     wxXmlResource::Get()->InitAllHandlers();

+    wxString m_originPATH;
+    wxGetEnv("PATH", &m_originPATH);
+    Manager::Get()->SetOriginPath(m_originPATH);
+
     Manager::SetToolbarHandler(toolbarAddonHandler);

     LogManager *log = Manager::Get()->GetLogManager();

[zetab]

Ok, i can reproduce this now...

I will look into it, but in theory it should not be a problem (beside, at least from my point of view, it is obvious a error in codeblocks) , because the current compiler is at the front of path, so it should always take this path first and so if there are clashes about naming it should always pick the right one.

Are you experiencing problems with this?

No, I haven't experienced any problem with this, it's just look strange to me.
I don't know whether this is a bug or a design in purpose.
If it's by design, I'm OK with it.

[BlueHazzard]

for keeping this around i created a ticket, because here in the forum it will get lost:
https://sourceforge.net/p/codeblocks/tickets/1351/