Rooba
/
ReC98
mirror of https://github.com/nmlgc/ReC98.git
1
1
Fork 0
Code Issues Packages Projects Releases Wiki Activity
ReC98/build16b.bat

38 lines
892 B
Batchfile
Raw Normal View History

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 second, 16-bit part of the ReC98 build process.
echo If this fails or shows other weird behavior, run BUILD16B separately in DOSBox.
REM (Yes, we don't use %0%, as it actually has to be %0 on DOS. Just spelling
REM out the name saves us that trouble.)
[Build] Keep TLINK from accidentally creating 1.MAP on every build
2017-03-10 19:46:00 +00:00
tlink >NUL
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
if errorlevel 9009 goto no_tlink
if errorlevel 216 goto 64_bit
[Build] Keep TLINK from accidentally creating 1.MAP on every build
2017-03-10 19:46:00 +00:00
tcc >NUL
[C decompilation] ZUNSOFT.COM, all of it And, of course, it recompiles into the exact binary ZUN shipped in 1997. Success! This project is so going to happen now.
2015-02-17 12:16:08 +00:00
if errorlevel 9009 goto no_tcc
if errorlevel 216 goto 64_bit
[Build] Use Borland's real-mode MAKER.EXE DOSBox-X seems to have some problems with it, or maybe that's just me having configured something wrong. In any case, it's not like we need that extra memory, so removing the need for the DPMI driver removes one more potential source of problems. Oh, and it has always been part of the devkit. :P
2018-03-19 22:52:42 +00:00
maker
Use a Makefile for the 16-bit part of the build process Well, that became unbearable pretty quickly. Not sure whether I'm doing all this Makefile business right, but this looks pretty nice. It doesn't really help much at this point though because the 32-bit part is still entirely separate and forces everything to rebuild all the time, but at least it aborts on C compiler errors.
2015-02-21 10:23:03 +00:00
if errorlevel 9009 goto no_make
if errorlevel 216 goto 64_bit
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
:64_bit
echo You're running a 64-bit OS. Run BUILD16B.BAT separately in DOSBox instead.
goto eof
[C decompilation] ZUNSOFT.COM, all of it And, of course, it recompiles into the exact binary ZUN shipped in 1997. Success! This project is so going to happen now.
2015-02-17 12:16:08 +00:00
:no_tcc
echo Could not find TCC.
goto tc4j_bin
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
:no_tlink
echo Could not find TLINK.
[C decompilation] ZUNSOFT.COM, all of it And, of course, it recompiles into the exact binary ZUN shipped in 1997. Success! This project is so going to happen now.
2015-02-17 12:16:08 +00:00
goto tc4j_bin
Use a Makefile for the 16-bit part of the build process Well, that became unbearable pretty quickly. Not sure whether I'm doing all this Makefile business right, but this looks pretty nice. It doesn't really help much at this point though because the 32-bit part is still entirely separate and forces everything to rebuild all the time, but at least it aborts on C compiler errors.
2015-02-21 10:23:03 +00:00
:no_make
[Build] Use Borland's real-mode MAKER.EXE DOSBox-X seems to have some problems with it, or maybe that's just me having configured something wrong. In any case, it's not like we need that extra memory, so removing the need for the DPMI driver removes one more potential source of problems. Oh, and it has always been part of the devkit. :P
2018-03-19 22:52:42 +00:00
echo Could not find MAKER.
Use a Makefile for the 16-bit part of the build process Well, that became unbearable pretty quickly. Not sure whether I'm doing all this Makefile business right, but this looks pretty nice. It doesn't really help much at this point though because the 32-bit part is still entirely separate and forces everything to rebuild all the time, but at least it aborts on C compiler errors.
2015-02-21 10:23:03 +00:00
goto tc4j_bin
[C decompilation] ZUNSOFT.COM, all of it And, of course, it recompiles into the exact binary ZUN shipped in 1997. Success! This project is so going to happen now.
2015-02-17 12:16:08 +00:00
:tc4j_bin
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 Please make sure that the BIN directory of Turbo C++ 4.0J is in your PATH.
goto eof
:eof