Add build batch files and some documentation about the build process
So yeah, that'll be our build environment - just plain batch files calling the
Borland command-line assembler, linker, and eventually C compiler. These are
the exact tools that ZUN used as well. There certainly are other assemblers,
compilers and linkers that could compile this code into 16-bit DOS
executables; Open Watcom is the only free one I know, and the master.lib
manual also mentions C compilers by Microsoft and Symantec. However, I favor
having one clear build path for a single toolchain that will, with the correct
command-line switches for each game, create builds that are bit-perfect to
ZUN's original ones over the possibility of cross-platform builds and the
maintenance nightmare they add.
So, Borland-only it is.
(Also, no Makefile, due to our messy build setup. I think I still prefer this
solution though, as we can have these really nice error messages that double
as build instructions without any dependencies on installed software.)
2015-02-15 22:32:32 +00:00
|
|
|
@echo off
|
|
|
|
echo Running the first, 32-bit part of the ReC98 build process.
|
|
|
|
|
2020-08-31 17:57:43 +00:00
|
|
|
: Windows 9x doesn't support stderr redirection, and always sets ERRORLEVEL to
|
|
|
|
: 2 if you attempt to do that, regardless of `tasm32`'s existence. NT properly
|
|
|
|
: returns 9009 if not found, or 0 otherwise.
|
|
|
|
set STDERR_IGNORE=
|
|
|
|
tasm32 >NUL 2>NUL
|
2020-08-29 12:13:54 +00:00
|
|
|
if errorlevel 9009 goto no_tasm32
|
2020-08-31 17:57:43 +00:00
|
|
|
if errorlevel 2 goto check_tasm32_win9x
|
2020-08-29 12:13:54 +00:00
|
|
|
|
2020-08-31 17:57:43 +00:00
|
|
|
: NT + TASM32 existing confirmed at this point
|
|
|
|
setlocal
|
|
|
|
set STDERR_IGNORE=2^>NUL
|
|
|
|
goto check_bcc32
|
|
|
|
|
|
|
|
: Re-run the actual TASM check for Windows 9x. Calling a nonexistent command
|
|
|
|
: leaves ERRORLEVEL untouched, so we have to override it ourselves first.
|
|
|
|
:check_tasm32_win9x
|
|
|
|
call set_errorlevel_to_1.bat
|
|
|
|
tasm32 >NUL %STDERR_IGNORE%
|
|
|
|
if errorlevel 1 goto no_tasm32
|
|
|
|
|
|
|
|
:check_bcc32
|
|
|
|
call set_errorlevel_to_1.bat
|
|
|
|
bcc32 >NUL %STDERR_IGNORE%
|
|
|
|
if errorlevel 1 goto no_bcc32
|
2020-08-29 12:13:54 +00:00
|
|
|
|
2020-08-30 21:33:47 +00:00
|
|
|
: Neither BCC32 nor TASM32 automatically create nonexisting output
|
2017-01-22 20:22:00 +00:00
|
|
|
: directories. Tup would, but not everybody can use it.
|
2020-09-05 23:12:42 +00:00
|
|
|
mkdir bin\zuncom %STDERR_IGNORE%
|
2020-08-31 17:57:43 +00:00
|
|
|
mkdir bin\Pipeline %STDERR_IGNORE%
|
2020-08-31 18:35:59 +00:00
|
|
|
for %%i in (1 2 3 4 5) do mkdir bin\th0%%i %STDERR_IGNORE%
|
2020-08-30 21:33:47 +00:00
|
|
|
|
2020-08-31 12:12:20 +00:00
|
|
|
call set_errorlevel_to_1.bat
|
|
|
|
tup version >NUL
|
|
|
|
if errorlevel 1 goto fallback
|
|
|
|
: NT returns negative values for things like DLL import failures
|
|
|
|
if not errorlevel 0 goto fallback
|
|
|
|
|
2017-01-22 20:22:00 +00:00
|
|
|
tup
|
2020-08-31 12:12:20 +00:00
|
|
|
goto eof
|
|
|
|
|
|
|
|
:fallback
|
|
|
|
echo [:(] Failed to run Tup (gittup.org/tup), falling back on a dumb full rebuild...
|
|
|
|
if not errorlevel 0 echo (Delete `tup.exe` to avoid the error message boxes in the future)
|
|
|
|
call Tupfile.bat
|
Add build batch files and some documentation about the build process
So yeah, that'll be our build environment - just plain batch files calling the
Borland command-line assembler, linker, and eventually C compiler. These are
the exact tools that ZUN used as well. There certainly are other assemblers,
compilers and linkers that could compile this code into 16-bit DOS
executables; Open Watcom is the only free one I know, and the master.lib
manual also mentions C compilers by Microsoft and Symantec. However, I favor
having one clear build path for a single toolchain that will, with the correct
command-line switches for each game, create builds that are bit-perfect to
ZUN's original ones over the possibility of cross-platform builds and the
maintenance nightmare they add.
So, Borland-only it is.
(Also, no Makefile, due to our messy build setup. I think I still prefer this
solution though, as we can have these really nice error messages that double
as build instructions without any dependencies on installed software.)
2015-02-15 22:32:32 +00:00
|
|
|
|
|
|
|
goto eof
|
|
|
|
|
|
|
|
:no_tasm32
|
|
|
|
echo Could not find TASM32.
|
|
|
|
echo Please make sure that the BIN directory of Turbo Assembler 5.0 is in your PATH.
|
|
|
|
goto eof
|
|
|
|
|
2020-07-09 19:55:01 +00:00
|
|
|
:no_bcc32
|
|
|
|
echo Could not find BCC32.
|
|
|
|
echo Please make sure that the BIN directory of Borland C++ 5.5 is in your PATH.
|
|
|
|
goto eof
|
|
|
|
|
Add build batch files and some documentation about the build process
So yeah, that'll be our build environment - just plain batch files calling the
Borland command-line assembler, linker, and eventually C compiler. These are
the exact tools that ZUN used as well. There certainly are other assemblers,
compilers and linkers that could compile this code into 16-bit DOS
executables; Open Watcom is the only free one I know, and the master.lib
manual also mentions C compilers by Microsoft and Symantec. However, I favor
having one clear build path for a single toolchain that will, with the correct
command-line switches for each game, create builds that are bit-perfect to
ZUN's original ones over the possibility of cross-platform builds and the
maintenance nightmare they add.
So, Borland-only it is.
(Also, no Makefile, due to our messy build setup. I think I still prefer this
solution though, as we can have these really nice error messages that double
as build instructions without any dependencies on installed software.)
2015-02-15 22:32:32 +00:00
|
|
|
:eof
|
2015-02-18 11:07:37 +00:00
|
|
|
echo -------------------------------------------------------------------------------
|