Cleanup Watcom compilation, setup, as recommended by @jmalak, and remove old sarcastic remarks that have outlived their usefulness.

joncampbell123 / doslib

Hackipedia DOSLIB, a general collection of useful libraries for writing MS-DOS software

GNU Lesser General Public License v2.1

206 stars 17 forks source link

Cleanup Watcom compilation, setup, as recommended by @jmalak, and remove old sarcastic remarks that have outlived their usefulness. #40

Open jmalak opened 5 years ago

jmalak commented 5 years ago

Please what is purpose of linux-ow.sh and owenv.sh script files? I don't understand why it has complete messy INCLUDE environment variable. Why OW tools setup is for 32-bit Windows if you compile for different targets? It results in following wrong message in shell scripts

"# why is this even necessary? why does dumbshit Watcom insist on including the WINNT headers for Windows 3.1 builds?"

It is caused by previous wrong OW setup. in other files <os>_INCLUDE variables are used and wrongly combined with INCLUDE variable.

Such OW setup can cause some hiden mistakes etc.

You should handle cross-compilation one way only, don't mix multiple mechanism.

full handling by <os>_INCLUDE and INCLUDE variables
full handling by command line -I option

By example OW build system is fully cross-compilation system and it uses "full handling by command line -I options" for flexibility. It requires to ignore all ..INCLUDE variables, it is ensured by using -x compiler option. I thing for your project you could use aproach with <os>_INCLUDE and INCLUDE variables

joncampbell123 commented 5 years ago

Windows 95 VXDs use the same linear executable format as Windows 3.1 386 files.

joncampbell123 commented 5 years ago

I should really separate the Windows VXD code out so it doesn't fail the compile.

It's very experimental and shouldn't be built by default.

I don't expect everyone to have the same GCC 7.1.0 + OW setup I do.

joncampbell123 commented 5 years ago

Is code compiled with Open Watcom supposed to refer to dsound.h as <direct/dsound.h> or should it be accessible as ?

DOSAMP isn't compiling right now.

Open Watcom has nt/directx/dsound.h

jmalak commented 5 years ago

It is fixed now by adding directx SDK to the include path list

jmalak commented 5 years ago

I will fix -bt=... option, it must be always defined for proper value. It will be:

Win3.1 (16/32 bit) -> -bt=windows  -> __WINDOWS__     $WATCOM/h;$WATCOM/h/win
Win32(s)           -> -bt=nt       -> __NT__          $WATCOM/h;$WATCOM/h/nt
WindowsNT          -> -bt=nt       -> __NT__          $WATCOM/h;$WATCOM/h/nt
16-bit OS/2        -> -bt=os2      -> __OS2__         $WATCOM/h;$WATCOM/h/os21x
32-bit OS/2        -> -bt=os2      -> __OS2__         $WATCOM/h;$WATCOM/h/os2
16-bit DOS         -> -bt=dos      -> __DOS__         $WATCOM/h
32-bit DOS         -> -bt=dos      -> __DOS__         $WATCOM/h

jmalak commented 5 years ago

After fixing targets zlib code diagnose problem with multiple OS_CODE macro definition which are not same. It looks like some mismatch between AUTOMAKE environment (config.h) and OW definitions. Zlib code is not aware about OW compiler, that configuration (in config.h) is probably wrong. Please review it.

jmalak commented 5 years ago

I think now main changes are finished. Following review/correction should be done.

each compiler command line must have defined -bt=... option valid for build target (it is defined in "co...mak" make files)
each compiler command line must have defined -I"..." option with OW header path valid for build target (it is defined in "co...mak" make files)
each linker command line must have defined "system" or "format" directive valid for build target (it is defined in "co...mak" make files)

joncampbell123 commented 5 years ago

@jmalak Will check. Thank you for your help. Does this help @sparky4 as well?

jmalak commented 5 years ago

I suppose yes, now build of doslib shoud not depend on OW configured target (environment variables), only required executable on the PATH and defined WATCOM environment variable. Theoreticaly if your build system will be ported to other host OS then you don't need to change anything in doslib wmake make files and it should work (I mean OW related things).

jmalak commented 5 years ago

One note about -zw option. If you use it for any target then it defines __WINDOWS__ macro and it completely confuse header files and can confuse conditionaly code if you use it for non-Windows 3.x environment. I fixed appropriate make files to be used -zw option only with -bt=windows (Windows 3.x 16-bit or OW 32-bit extender). It could break some code which relate to something specific for 16-bit Windows even if it was non-Windows target as OS/2, NT or DOS.

joncampbell123 commented 5 years ago

@jmalak That makes sense, -zw means "generate code for Microsoft Windows".

Could the compiler print a warning if -zw is used for anything other than Windows?

jmalak commented 5 years ago

I have a few ideas how you can improve/simplify OW wmake make files (compatible with both versions OW1.9 and OW2.0) and be more cross-platform independent (independent on host where run)

!include directive is capable to use '/' as path separator, then you should use forward slash instead of back slash, double quotes have sense only for path with spaces
```
!include test/test/make.mak     # it is correct for all host platforms`
```
macros for linker, you use library <name of library>, better is to use only <name of library> because such macros can be used for dependencies, to combine multiple libraries and also for linker by library {list of macros with libraries}. The same note for object file.
```
LIBS = $(LIB1) $(LIB2) test.lib ...
OBJS = $(OBJ1) $(OBJ2) test.obj ...
```

test.exe : $(OBJS) $(LIBS) *wlink name test.exe library { $(LIBS) } file { $(OBJS) }

- macros for librarian, you have doubled list of object files, one for dependencies and one for library command list. Better is to use macro as template for both and expand it for differend macro values, see example below

OBJS = $(PRFX)obj1.obj $(PRFX)obj2.obj

PRFX =