OpenWatcom (W32) Compiler template problem

[Tim]

System = Windows XP SP3

Codeblocks 8.02 and 20.03 (Possibly others in between)

I've just noticed a problem with the "Open Watcom" compiler template/Plugin.

If a "copy" is made of the "OpenWatcom (W32) Compiler" template, Say for example,  "Copy of OpenWatcom (W32) Compiler" (Without any modifications)

Then an attempt to compiler & link a basic "Console" application with it, it will generate a very different warning & error output from the original template.

[Tim]

I've now found a "Work Around" for the problem, which I think will also help to define the problem.

My original aim was to create a compiler template to produce Watcom dos16 applications using both wcl.exe and wlink.exe.

Working on a fresh copy of XP (SP3) and a fresh CB 8.02 install, I would:-


1. Create a copy of "OpenWatcom (W32) Compiler" template and name it "Copy1".

2. Modify the "Copy1" template with the necessary changes to build a Dos16 App.

3. Create a new Dos console project "wd1" specifying the "Copy1" template for the compiler.

The Problem............
The full command would be reported as I expected it to look, but the
build would fail but without reporting any actual results or warnings or errors.


The "Work Around".........


1. Modify the original "OpenWatcom (W32) Compiler" template with the necessary changes to build a Dos16 App.

2. Create a copy of the "modified" "OpenWatcom (W32) Compiler" template and name it "Copy2".

3. Create a new Dos console project "wd1" specifying the "Copy2" or  the modified "OpenWatcom (W32) Compiler" template for the compiler.

The build will now work correctly, and report results and any actual warnings or errors correctly if any are introduced to the source files.


I have not tested the "work around" on CB 20.05, only on  CB 8.05

After I install CB 20.05  I have to apply a patch
https://forums.codeblocks.org/index.php/topic,23924.msg167864.html#msg167864
to the installation before it will run

It would seem that CB 25.03 may also need a similar patch to run on XP
A message box appeared similar to:-    api-ms-win-crt-convert-l1-1-0.dll was not found.

***********************

In 2000 I was acutely embarrassed when trying demonstrate some bespoke software
to a room full of executives, only to be met with a message msvc runtime dll not found.
After that I bought a PC for testing only, and invested in a copy of Installshield.

Soon after that I experimented in copying OS's to harddisks with multiple primaries, to speed
up the process of obtaining fresh OS test installations. I briefly described my method here :-
https://www.xpforums.com/threads/open-file-security-warning-do-you-want-to-open-this-file.935598/#post-3274916

Although it's still a pain to test with each OS, at least it can usually still be done on the same development PC,
and only takes about 5 minutes per OS to get the answer to "will it run?".

[Tim]

Another update...


It looks like I've only got it partially right, depending on which CB version I'm using.

On CB 8.02 it 'appears' no copies of the Watcom compiler template of will work in multi obj file senarios.
This is because the 'file' directive and the obj file ',' comma separator are hard-coded, and don't come across in the template copy.

The 'file' directive is not a problem as it can be added to the command line macro.
But the obj file list comes pre-built via the '$link_objects' variable, and I can't see a way to change it.
However later versions of CB have user selectable separator character.

So for CB 8.02, the upshot would 'appear' to be, that all different Watcom compiler builds need to be modifications of the original "OpenWatcom (W32) Compiler" template which cannot be saved as a copy.

That said, perhaps I'll discover another twist tomorrow.

Maybe as CB 8.02 and Watcom Dos 16bit builds are more likely to be used with Windows 98se it strikes me as worth thinking about rebuilding it with a revised "OpenWatcom (W32) Compiler" template and a user selectable separator character option.

[Tim]

After coming across the following post:-
https://forums.codeblocks.org/index.php/topic,19721.0/all.html
I 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#msg176583

If 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#msg174896

When 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.