gcc/Linux/GNU make fails to build country.sys
Closed this issue · 13 comments
With the changes in 9b6a857 the gcc/Linux host build no longer succeeds in building country.sys. One problem is that make expects a tab but this commit used 8 blanks:
cp sys.com ../bin
make[1]: Leaving directory '[...]/kmak/sys'
cd kernel && make production
make[1]: Entering directory '[...]/kmak/kernel'
GNUmakefile:47: *** missing separator (did you mean TAB instead of 8 spaces?). Stop.
make[1]: Leaving directory '[...]/kmak/kernel'
make: *** [makefile:117: all] Error 2
$
Even fixing that we get another error during make:
cp kernel.map ../bin/KGC8632.map
cd ../country
make all
make[2]: Entering directory '[...]/kmak/kernel'
make[2]: *** No rule to make target 'all'. Stop.
make[2]: Leaving directory '[...]/kmak/kernel'
make[1]: *** [GNUmakefile:47: ../bin/country.sys] Error 2
make[1]: Leaving directory '[...]/kmak/kernel'
make: *** [makefile:117: all] Error 2
Time to standardise on gnumake to be used for all compilers? Perhaps then we could say make -C country all?
I think as long as Watcom C is supported as a compiler, so should be wmake. In this case the bug is trivial to fix.
for now I'm not making any major changes, but ultimately yes I am going to switch to all platforms and all compilers requiring gnu make. It's too much of a maintenance burden to keep supporting different variations. A build works here but not there, a simple change breaks someone else's build. When it happens I do plan to provide binaries to download for DOS and Windows and ensuring documented requirements for Linux. I thought of requiring wmake or dmake for all platforms but I think gmake is more widely used and will require less platform specific tweaks.
As a side note, tabs vs spaces are really annoying and I really need to setup a source formatting step in the pr process. But I will create a discussion for that.
fixed, but I don't like it
I've been building in DOS using the script build.bat which according to the top level makefile is the way to do it on DOS. See
Lines 1 to 5 in edd0732
Just to be sure it wasn't using the makefile behind the scenes, I deleted it and was still able to build using the build.bat.
So I don't understand why the original fix to be DOS compatible was required? So were you able to build on DOS @bocke just using the makefile? What compiler and make were you doing this with?
@bocke I just found your original issue report and that has the details, so no need to reply. I'm off to study this now, thanks.
@andrewbird
Basically, "&&" is a Windows NT CMD extension. It's available from NT4 and higher and shouldn't exist in DOS.
See here for more info (specifically, under oneliners paragraph):
https://www.robvanderwoude.com/condexec.php
@bocke thanks I have it now. I had misread your PR and thought that you had been using the top level makefile from DOS, which surprised me.
Well, I just read this issue and I'm sorry for causing it. I actually just made a small correction using GitHub web interface. Nothing that should've broken the build. So I don't really understand what caused the problem.
Edit:
I see: tabs, spaces, newlines... I tought we are in 21st century and don't need to worry about those anymore. :)
About GNU Make standardization: I'm all for it. You don't really have to use wmake with Watcom. GNU Make works as well, maybe even better as it's pretty standardized.
I think the problem came about because in a makefile each line of a rule is executed in a separate shell. On Linux each shell has a distinct current working directory, whereas on DOS it's per drive. See https://stackoverflow.com/questions/10121182/multi-line-bash-commands-in-makefile. So on Linux cd'ing into a directory on the first line has no effect on the following one.
I forgot to close this.