Hi Rugxulo, thanks for the advice!
> Is makefile.bor still maintained? Do you still (also) support building > it with that toolset (presumably freeware-ish TC++ 1.01 would work)? Yes! At the moment I have it compiling with Borland C++ 3.1, Turbo C++ 3.0 and Open Watcom 1.9. While mainly developing under Watcom I think it is a good idea to have it compile with different toolchains. Helps finding bugs. However, the makefile I started working on did not mention Turbo C++ 1.01, so I did not test that. If someone requests Turbo C++ 1.01 support I will see what I can do. GCC IA-16 support could also be desirable. > it seems you still use NASM (instead of WASM). Seems redundant > (no offense). I have not touched the NASM code yet. I could change the code to assemble under WASM, but because I plan to still support the Borland toolchains I am not aware of any benefit that would bring. > 2. "if exist *.OBJ @rm *.OBJ" is unnecessary, and you should be able > to delete multiple files with Wmake's built-in "rm", e.g. "rm -f *.obj > *.err *.lnk" with no error messages if not found. > > 3. Oh! And %UPX% is possibly a bad variable name since I think that's > what the environment variable is also named, so that will override any > internal makefile variable by default (if the user has set it). I > recommend "PACKER" and "PACKERFLAGS", but this is not majorly > important. Done as you suggested. > 1. Invoking TLINK with a toolset path is unnecessary. You can use > "tcc" (or bcc) to link as well. > 2. You also don't need to manually create temporary linker response > files. (I forget exactly, but it's something like @&&^ ... ^ to do it > automatically.) > Regarding OpenWatcom: > > * https://github.com/boeckmann/fdisk/blob/master/SOURCE/FDISK/MAKEFILE.WAT > > 1. Again, you don't need to manually create a temporary linker > response file. Try using "LD = *wlink" instead, it will automatically > handle long command lines. I guess it is a thing of preference, but at least for Watcom I actually like the generation of separate linker files. Nevertheless dropping it at least for Borland is perhaps a good idea if that removes the need for specifying the toolchain installation path. I will try to change that. Greetings, Bernd _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
