After coming across the following post:-
https://forums.codeblocks.org/index.php/topic,19721.0/all.htmlI started snooping around in the DirectCommands.cpp
It 'appears' that the reason the "file" and the "," comma separator are lost in copies of "OpenWatcom (W32) Compiler" is because
tests are made on a variable called CompilerID which is "ow" for the "OpenWatcom (W32) Compiler" target, but it is different in the case of a 'copy' of the "OpenWatcom (W32) Compiler" target.
However the target copy does have variable called ParentID, which I believe is set to "ow". So it makes sense to test both variables in DirectCommands.cpp.
Around line 537 onwards...
wxArrayString DirectCommands::GetTargetLinkCommands(ProjectBuildTarget* target, bool force)
I've replaced
***********************
// bool IsOpenWatcom = target->GetCompilerID().IsSameAs(_T("ow"));
***********************
With
****************************************
bool IsOpenWatcom = false;
if(target->GetCompilerID().IsSameAs(_T("ow")) == true)
{
IsOpenWatcom = true;
}
Compiler* pCompiler = CompilerFactory::GetCompiler(target->GetCompilerID());
if(pCompiler->GetParentID().IsSameAs(_T("ow")) == true)
{
IsOpenWatcom = true;
}
******************************************
// IsOpenWatcom is used 4 times
// Test if the Compiler target is "OpenWatcom (W32) Compiler" (GetCompilerID == "ow"
// or if the Compiler target was derived from "OpenWatcom (W32) Compiler" such as
// "Copy of OpenWatcom (W32) Compiler" (GetParentID == "ow"
Also around line 616, I've Rem'd out 2 lines
// if (IsOpenWatcom && target->GetTargetType() != ttStaticLib)
// linkfiles << _T("file ");
To stop the word 'file' being prepended to $link_objects variable/string.
And instead added the word 'file' to lines around 330 in the command macro pre-load code, in the compiler template file compilerOW.cpp
**********************************************************
m_Commands[(int)ctLinkExeCmd]
.push_back( CompilerTool(wxT("$linker option quiet $link_options $libdirs file $link_objects name $exe_output $libs $link_resobjects")) );
m_Commands[(int)ctLinkConsoleExeCmd]
.push_back( CompilerTool(wxT("$linker option quiet $link_options $libdirs file $link_objects name $exe_output $libs $link_resobjects")) );
m_Commands[(int)ctLinkDynamicCmd]
.push_back( CompilerTool(wxT("$linker option quiet $link_options $libdirs name $exe_output $libs file $link_objects")) );
m_Commands[(int)ctLinkStaticCmd]
.push_back( CompilerTool(wxT("$lib_linker -q $static_output file $link_objects")) );
**********************************************************
I then rebuilt the main project (minus the user plugins) with Widgets 2.8.12 as a non-unicode release build and zipped up the results.
The zip is called "codeblocks-8.02-win32-ansi-wx2812-V2.7z" and it can be found at github, details in this post:-
https://forums.codeblocks.org/index.php/topic,25925.msg176583.html#msg176583If you follow the instructions on github first, regarding "codeblocks-8.02-win32-ansi-wx2812.7z" (basically version 1)
Then copy the contents of "codeblocks-8.02-win32-ansi-wx2812-V2.7z" over the first.
If you want the compiler and linker build messages to have line breaks between each command see this post:-
https://forums.codeblocks.org/index.php/topic,24610.msg174896.html#msg174896When I tested the above modifications, the link process would still often fail.
The command line would look OK, but codeblocks would report it as failed, but without a reason or error code.
If I copied the failed command line to a dos window it would work OK.
I then created a dos exe program that simply outputted all of its incoming arguments to a text file, and then substituted it for the wlink.exe to see what the command line actually was.
It showed the no command line was actually outputted from codeblocks for a failed link process.
After some experiments the problem 'seems' to be caused by the length of the command line.
The command line could be shortened 'in theory' by creating & attaching an environment variable set to the project. I've not proved this actually works.
Recent Posts
!