!!! Important change in build system, it requires update of your setvars script copy !!!

[jmalak]

I changed build system by introducing new environment variable OWTOOLS.
This variable must be setup to one of following values:
WATCOM - use Open Watcom for bootstrap build
VISUALC - use Microsoft Visual C++ for bootstrap build
GCC - use GNU gcc compiler for bootstrap buil
CLANG - use Clang compiler for bootstrap build
INTEL - use Intel C++ compiler for bootstrap build
if it is not defined or use unsupprted value then default to WATCOM
OWUSENATIVETOOLS is now useless therefore it is removed.

[pchapin]

Thanks, Jiri. I successfully built the system on my Windows 7, 64 bit system using 64 bit Open Watcom as my build compiler. BTW, I added %WATCOM%\binnt64 to the path. I'm not sure if that's something that should be in the setvars.bat template or not. Maybe not.

[ABratovic]

This occurs if you have installed 64bit OW windows executables built
with 64bit compiler so as to bootstrap build 32bit OW using OWTOOLS=WATCOM

But, if you have installed a 32bit OW, such as OW1.9 then binnt64 does
not exist.

So, in Peters case he could comment out OWTOOLS to undefine it and run
the OWSETVARS.bat in the 64bit OW he installed before running build.bat
which will set his paths correctly.
(edit) this may not work now

I suggest that there be a OWTOOLS=WATCOM64

OWTOOLS=WATCOM will set the compiler vars for the user (as it does now)

OWTOOLS=WATCOM64 will set the compiler vars for the user

OWTOOLS not defined will require the user to set the compiler vars
before running setvars (as it does now)

In setvars.bat
if '%OWTOOLS%' == 'WATCOM64' goto usewatcom
if not '%OWTOOLS%' == 'WATCOM' goto docs_setup

usewatcom:
..
..
set INCLUDE=%INCLUDE%;%WATCOM%\h\nt
set PATH=%WATCOM%\binnt;%PATH%

if not '%OWTOOLS%' == 'WATCOM64' goto docs_setup
set PATH=%WATCOM%\binnt64;%PATH%

:docs_setup

Remember, 64 bit OW can not (yet) build 64 bit OW, must currently use
64bit GCC, MSVC, Clang or Intel compiler.

Peter C. Chapin wrote:

Thanks, Jiri. I successfully built the system on my Windows 7, 64 bit
system using 64 bit Open Watcom as my build compiler. BTW, I added
|%WATCOM%\binnt64| to the path. I'm not sure if that's something that
should be in the setvars.bat template or not. Maybe not.

—
Reply to this email directly or view it on GitHub
#125 (comment).

[jmalak]

I externalize setup of OW used for building process.
setvars script don't configure OW compiler anymore.
Now it is your responsibility to configure your preferred version of OW (OW version or 32/64-bit binary version) before configure it by setvars and run build process.
Appropriate setup can be done by script or can be included in your copy of setvars script.

[ABratovic]

The concept of custom compiler setup matches my custom copy of setvars.bat

REM Set this entry to identify your toolchain used by build process
REM supported values are WATCOM VISUALC INTEL
set OWTOOLS=WATCOM

REM after the above lines I add the following two
if '%OWTOOLS%' == 'VISUALC' call "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall" x64
if '%OWTOOLS%' == 'WATCOM' call "C:\ow\ow19\owsetenv.bat"

Question
GCC & CLANG are used to build OW on linux, can windows versions of these build OW on windows?

[jmalak]

It is not supported.
In each setvars script (host dependent) is note about supported values.
For Windows it is WATCOM VISUALC INTEL.
Unfortunately if some real interest for unsupported toolchain on some host platform then we can invest some time to modify build make files (mainly build/mif/local.mif) and test it.
Now it is simpler then before.

[ABratovic]

Your latest setvars.bat is simpler for custom installations but the doco will need to be updated that the compiler variables need to be set before running setvars.bat, maybe suggesting my custom edit shown in earlier post to set compiler vars from within custom setvars.bat
I have no interest for clang on windows as yet. Reason I asked is this article http://tinyurl.com/k3745h2

[ABratovic]

Jiri, now that 32bit and 64bit builds fully build (exe,doc and zip) it may a good time to update the binary executables on Sourceforge.

[pchapin]

I did tweak BUILD.md a little to give readers a heads up about needing to set up the compiler environment. The presentation could probably be better than it is.

[jmalak]

Peter, Thanks.
I added "builder buildtest" command description.
It is useful for testing during development without need to do any configuration change, it does testing in build tree.

[jbailey8]

I've been trying to build the latest git version of the openwatcom 64 bit src tree, and I can build most
of it, but when I get to 'bld\idedemo\threed\nt' folder, everything stops with wmake saying it can't
find 'project.mk', I've compared this to other src tree dumps and I didn't see that file in any of
those either, does anyone know where I can find this file?

Thanks!

[jmalak]

This file is created dynamicaly by bide2make utlity from *.tgt file
Please check, build log for result of command bide2make ......

[jbailey8]

I checked the build log, there is no mention of bide2make being ran at all.
but it is being ran in the directory before the directory I mentioned.

[jbailey8]

Well, this is wonderful, I tried to do another build and now it won't even do the very first thing
which is trying to build wsplice.exe, the errors are it can't find 2 header files, but when I check
the path, the files come back as being available (where watcom.h for example, brings a path back),
so I changed the 2 header files listed from "" to <> to see if that would work, and it still can't
find them, so at the moment I'm stumped, I've rechecked setvars.bat and the other batch
files involved and they seem fine. If anyone has any ideas, please speak up.

Thanks!

[jbailey8]

Update, I decided to check the base system paths even though I wasen't aware of changing
them, and I found some incorrect entries, I deleted them and re-ran everything and now it
seems to be working, so... I actually answered my own question, if you run accross this
kind of problem check those system paths and variables, you never know.