WLIB: changed argument handling breaks some build scripts

[boeckmann]

In comparison to the 1.9 version, WLIB does not accept -l argument without a file name given. This breaks backward compatibility and some build scripts, like the FreeCOM build, which works with WLIB 1.9 but not v2. OW 1.9 WLIB defaults to <libname>.lst for the listing file name.

I am sure there was a good reason to change this. But perhaps it should be considered to still allow -l without a file name given.

[jmalak]

wlib command line processing was completely reworked that some difference from OW 1.9 can happen.

[jmalak]

It should be fixed now.
Please re-check issue with new build.

[boeckmann]

I tested it! -l is now accepted without a parameter. THANKS!

However, the FreeCOM build script is a little bit weired. It results in the following being executed:

wlib -n -c -l strings.lib @strings.rsp # strings.lst

I wonder why this even worked with WLIB 1.9, as I found no documentation of # in the OpenWatcom documentation. It seems that WLIB? 1.9 somehow treated this as a line terminator, ignoring the strings.lst. WLIB v2 does it not ignore, so the build still fails (at least under Windows) with

Error! Invalid command line near '# strings.lst'

But I think its not OpenWatcom to blame here.

My guess is that the original author implemented it under Unix-like operating system and depended on the shell treating # as a line terminator?!?

No idea if you consider this to be a compatibility problem, as the old behaviour does not seem to be documented anywhere?

[jmalak]

Thanks for wlib -l option functionality confirmation

To make file, I am not sure if I understand the issue.
generally wmake make file uses (#) character as in-line comment that from this position rest of line should be ignored.

Please give me more details what is expected etc. and what command line you use for wmake to be able understand issue.

If it is not make file and it is some batch file then it could be issue because new wlib command line processing is more stricter (uses program generated command line parser).
That I need better understand how it is used.
Please if possible could you give me reference to your project where this construct is used.

[boeckmann]

Sure :)

https://github.com/FDOS/freecom/blob/ff675135ea9a43144ad3fd95f87c34663d9b6095/mkfiles/watcom.mak#L33

There $LIBLIST is defined to be #.

And it is used for example here:

https://github.com/FDOS/freecom/blob/ff675135ea9a43144ad3fd95f87c34663d9b6095/suppl/src/suppl.mak#L87

With the intention of "commenting out" the given file. I admit its an ugly construct.

However, the following works with WLIB 1.9 even if RUNNING DIRECTLY from CMD.EXE:

>c:\watcom\binnt\wlib -n -c -l strings.lib @strings.rsp # strings.lst

But it fails with WLIB 2:

>c:\watcom2\binnt\wlib -n -c -l strings.lib @strings.rsp # strings.lst
Error! Invalid command line near '# strings.lst'

This construct may be used because the original author wanted this to be portable between different tool chains, especially also with the Borland tools, where $LIBLIST ist defined to be ,.

[jmalak]

Thanks.
I will review but it looks like bug or undocumented feature in OW 1.9 for me which was used by FDOS.
Now it is not supported by OW 2.0 due to new command line parser with documented features.
I thing that best it should be abandoned for Open Watcom at all, simply replace it by blanks, because it looks like comment for OW 1.9. It is very strange construct not used by any Open Watcom tool except wlib.
May be that OW 1.9 take rest of line after response file as part of response file, but OW 2.0 process it as new argument which is wrong.
I will check, but I don't want to add such non-transparent functionality to OW 2.0.

[boeckmann]

I will check, but I don't want to add such non-transparent functionality to OW 2.0.

Yes I understand, as it is undocumented and inconsistent to the other programs. The # seems indeed to be treated as comment start by WLIB 1.9. Everything that follows seems to be ignored.

[jmalak]

It looks like the usage of # is undefined behaviour and works with older OW wlib and FDOS use it.
I recommend to not use # character on wlib command line and use only well defined options.
removing # character solution is compatible with any WATCOM or Open Watcom version of wlib and will be transparent.

I will check the # issue in details (looks like related to response file usage) and return back to you.

I checked processing on both versions and # character is processed as comment in response file but not on command line.
OW 1.9 continue content of response file by rest of command line and therefore # character end of command line processing on OW 1.9 without problem (as comment) but fail on OW 2.0.
I think the OW 2.0 processing is correct but OW 1.9 processing is bug.
No body report it on OW 1.9 because it is a little illogical and nobody use it, but FDOS use this "undefined" behaviour and it is issue on OW 2.0.
The best solution is remove this "comment" from wlib command line.

[jmalak]

It is fixed in freecom by FDOS/freecom#113