Problems using OpenWatcom C (C::B bugs)

[bugmenot]

Hi @all!
I really like C::B, especially for the amount of C-Compilers that are supported (I use it with VC, Borland, MinGW and I'm starting to use Watcom).

There are some problems that seem to be surely bugs in C::B:
1. Compile with more than one "processes for parallel builds" (Settings -> Compiler Settings -> Other) is broken, results in

Error: Unable to open temporary file "__wcl__.lnk" - Permission denied

on compiling on the 2nd/3rd,... process.
The problem lies in the linker, according to Open Watcom Toolsthere is a linker option

fd[=<directive_file>] keep directive file and, optionally, rename it (default name is "__WCL__.LNK").

if it is not used, the standard file is used two/three/more times which won't work. It could be a good idea to set the file to name of source.lnk and delete it after the file is built.
Temporary Workaround: use no parallel build

2a. Linking - Path of Linker Search directories should be used in double quotes. Currently it's taken as it is written in Compiler Options (one could add the quotes there by hand) but it wouldn't harm if these are always passed to the linker in double quotes. If the Watcom directory contains spaces double quotes have to be used. This is used currently,

wlink.exe option quiet system nt_dll debug all LIBP D:\Some Progs\Watcom\lib386;D:\Some Progs\Watcom\lib386\nt name [...]

, better would be

wlink.exe option quiet system nt_dll debug all LIBP "D:\Some Progs\Watcom\lib386";"D:\Some Progs\Watcom\lib386\nt" name [...]

Temporary Workaround: Use 8.3 names or add double quotes by hand or don't use spaces in the paths

2b. Linking - Path of obj file names cannot contain space names (because of wrong used quotes)
Currently double quotes are used but this result in

Error! E3033: directive error near ...

. Everything after the word "file" has to be in single quotes, not double ones (I know, this is really weird, but that's the way it is).
Temporary Workaround: Use 8.3 names or don't use spaces in the paths

It would be nice if these points could be fixed - especially the first one.
Thank you!

[MortenMacFly]

Hi @all!

Multiple processes are not supported by some compilers or need strange workarouncds. This is known. Why don't you set this option you are referring to in the compiler options of C::B? then you are done. Settings this as default might break something other.

Concerning the quotes: For now, you can change the compiler / linker command in the advanced options for the compiler and you are done, too. I'll keep that in mind to make the quoting happen only if needed. This (btw) should actually already happen so I really wonder what version of C::B you have (you didn't say anything about that). If it's 08/02 than this might already been fixed in the meantime. Try a nightly in that case.

[bugmenot]

Thank you for the quick response. I'm using current nightly.

To 1: For the multiple processes I gave a possible workaround but this must be done by C::B. I think for every compiler where parallel building isn't supported now (because there is a workaround needed which isn't known or the workaround isn't implemented) the field should be disabled. Maybe you can do this? What about implementing the workaround for Watcom I've mentioned?

For the quotes (2a): They are not set in $libdirs (and therefore cannot be set with advanced options). This should be done by C::B. The workaround is to set them in linker paths directly for every entry but C::B should be able to do so when transferring all entries to $libdirs.

For the quotes (2b): They are set if needed, but they are wrong.

Everything after the word "file" has to be in single quotes, not double ones (I know, this is really weird, but that's the way it is).

[MortenMacFly]

the field should be disabled. Maybe you can do this? What about implementing the workaround for Watcom I've mentioned?

I can't because we don't have the compilers under our "control". Imagine a user creates a copy of a compiler and adjusts it to his/her needs (take another GNU compiler suite for embedded development for example). So a copy of a compiler must necessarily be of the base compiler at all. We simply don't want to limit the compilers in any way. We focus on a very flexible compiler framework that allows for adjustments as desired. We won't limit this in any ways. As long as you can do the work-arounds in the compiler setup or simply disable multi-treading if your compiler does not support it everything is "just fine".

For the quotes (2a): They are not set in $libdirs (and therefore cannot be set with advanced options). This should be done by C::B. The workaround is to set them in linker paths directly for every entry but C::B should be able to do so when transferring all entries to $libdirs.
For the quotes (2b): They are set if needed, but they are wrong.

Everything after the word "file" has to be in single quotes, not double ones (I know, this is really weird, but that's the way it is).

I tried, but I cannot reproduce both issues. What compiler are you using exactly? (Version?!) Did you try a recent Watcom? We had a couple of changes after 08/02 to address issues with this compiler. The issues were all solved and I for myself can compile a project in a path with spaces just fine. Did you adjust the compiler settings somehow? What happens if you reset them? (E.g. remove your whole C::B config temporarily and have C::B initialise this compiler from scratch).