Closed jwt27 closed 2 years ago
Hold on, there are more issues. Don't merge this yet.
gcc.arg
wasn't being created since %.o
didn't have a dependency on it. Not sure how that ever worked on other platforms.
Fixed now for all targets, let's see if appveyor agrees.
Last patch reverted for Borland and Visual C, it didn't seem to work there.
... but gcc.arg
is still not being generated on Mac, and I really don't see why.
2022-03-17T19:46:59.0115690Z Generating DJGPP makefile, directory and dependencies
2022-03-17T19:46:59.3633610Z Run GNU make to make target:
2022-03-17T19:46:59.3634600Z 'make -f djgpp.mak'
2022-03-17T19:46:59.4274560Z nasm -f bin -l asmpkt.lst -o asmpkt.bin asmpkt.nas
2022-03-17T19:46:59.4306740Z echo 'const char *w32_cflags = "-O3 -g -I. -I../inc -DWATT32_BUILD -W -Wall -Wno-strict-aliasing -march=i386 -mtune=i586 -O2 -g -ffunction-sections -fdata-sections -fgnu89-inline";' > build/djgpp/cflags.h
2022-03-17T19:46:59.4314010Z i386-pc-msdosdjgpp-gcc -E @build/djgpp/gcc.arg cpumodel.S > build/djgpp/cpumodel.iS
2022-03-17T19:46:59.4450140Z i386-pc-msdosdjgpp-gcc: error: build/djgpp/gcc.arg: No such file or directory
2022-03-17T19:46:59.4457690Z make: *** [build/djgpp/cpumodel.o] Error 1
2022-03-17T19:46:59.4458260Z make: *** Waiting for unfinished jobs....
2022-03-17T19:46:59.4791450Z echo 'const char *w32_cc = "i386-pc-msdosdjgpp-gcc";' >> build/djgpp/cflags.h
2022-03-17T19:46:59.5433910Z ../util/linux/bin2c asmpkt.bin > pkt_stub.h
2022-03-17T19:46:59.6530570Z ##[error]Process completed with exit code 1.
This isn't ready yet because it still won't compile on Mac. See output from make --debug
:
2022-03-17T21:29:48.8852180Z Generating DJGPP makefile, directory and dependencies
2022-03-17T21:29:49.1539360Z Run GNU make to make target:
2022-03-17T21:29:49.1540210Z 'make -f djgpp.mak'
2022-03-17T21:29:49.1896620Z GNU Make 3.81
2022-03-17T21:29:49.1897770Z Copyright (C) 2006 Free Software Foundation, Inc.
2022-03-17T21:29:49.1898630Z This is free software; see the source for copying conditions.
2022-03-17T21:29:49.1899020Z There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
2022-03-17T21:29:49.1899330Z PARTICULAR PURPOSE.
2022-03-17T21:29:49.1899470Z
2022-03-17T21:29:49.1900090Z This program built for i386-apple-darwin11.3.0
2022-03-17T21:29:49.1900380Z Reading makefiles...
2022-03-17T21:29:49.2198240Z Updating goal targets....
2022-03-17T21:29:49.2198860Z File `all' does not exist.
2022-03-17T21:29:49.2199190Z File `pkt_stub.h' does not exist.
2022-03-17T21:29:49.2200610Z Must remake target `pkt_stub.h'.
2022-03-17T21:29:49.2201540Z nasm -f bin -l asmpkt.lst -o asmpkt.bin asmpkt.nas
2022-03-17T21:29:49.2236110Z File `build/djgpp/cflags.h' does not exist.
2022-03-17T21:29:49.2237090Z Must remake target `build/djgpp/cflags.h'.
2022-03-17T21:29:49.2238280Z echo 'const char *w32_cflags = "-O3 -g -I. -I../inc -DWATT32_BUILD -W -Wall -Wno-strict-aliasing -march=i386 -mtune=i586 -O2 -g -ffunction-sections -fdata-sections -fgnu89-inline";' > build/djgpp/cflags.h
2022-03-17T21:29:49.2244940Z File `../lib/libwatt.a' does not exist.
2022-03-17T21:29:49.2259870Z File `build/djgpp/cpumodel.o' does not exist.
2022-03-17T21:29:49.2265370Z File `build/djgpp/gcc.arg' does not exist.
2022-03-17T21:29:49.2296430Z Must remake target `build/djgpp/gcc.arg'.
2022-03-17T21:29:49.2300830Z Successfully remade target file `build/djgpp/gcc.arg'.
2022-03-17T21:29:49.2301630Z Must remake target `build/djgpp/cpumodel.o'.
2022-03-17T21:29:49.2302500Z i386-pc-msdosdjgpp-gcc -E @build/djgpp/gcc.arg cpumodel.S > build/djgpp/cpumodel.iS
2022-03-17T21:29:49.2303430Z File `build/djgpp/accept.o' does not exist.
2022-03-17T21:29:49.2304580Z Must remake target `build/djgpp/accept.o'.
2022-03-17T21:29:49.2350160Z i386-pc-msdosdjgpp-gcc: error: build/djgpp/gcc.arg: No such file or directory
2022-03-17T21:29:49.2357740Z make: *** [build/djgpp/cpumodel.o] Error 1
2022-03-17T21:29:49.2358300Z make: *** Waiting for unfinished jobs....
2022-03-17T21:29:49.2717120Z echo 'const char *w32_cc = "i386-pc-msdosdjgpp-gcc";' >> build/djgpp/cflags.h
2022-03-17T21:29:49.3526450Z ../util/linux/bin2c asmpkt.bin > pkt_stub.h
2022-03-17T21:29:49.4102710Z ##[error]Process completed with exit code 1.
It says it gcc.arg
is successfully remade, but then gcc somehow can't find it. Very confusing. Any ideas what could be wrong?
Any ideas what could be wrong?
Maybe if should be @./build/djgpp/gcc.arg ...
. Also try changing that macro into:
define create_response_file
+ $(info Creating $(1))
$(file > $(1))
$(foreach f, $(2), $(file >> $(1),$(strip $(f))) )
endef
I already tried with ./
last night, that didn't work. Maybe it needs an absolute path? I'll try that and add the info line.
Absolute path didn't help. Next attempt:
diff --git a/src/makefile.all b/src/makefile.all
index d98bbbb..198b22b 100644
--- a/src/makefile.all
+++ b/src/makefile.all
@@ -1485,9 +1485,11 @@ lang.c: lang.l
$(C_ARGS): $(MAKEFILE_LIST)
$(call create_response_file, $@, $(CFLAGS))
+ touch $@
$(LIB_ARGS): $(OBJS) $(MAKEFILE_LIST)
$(call create_response_file, $@, $(OBJS))
+ touch $@
@ifdef HIGHC DJGPP
$(LINK_ARGS): $(OBJS) $(MAKEFILE_LIST)
GNU Make 3.81
Maybe this is too old?
Edit: I found this article regarding MacOS and GNU-make: https://apenwarr.ca/log/20181113
Likely yes. All the GNU software on Mac seems to be very old. It's weird though how it has no problem building binutils and gcc, which have much more complicated Makefiles.
It seems the $(file)
function is just broken on Mac. It works now using plain echo
.
I see the removal of a @
in your last commit was ok for e.g. visual_release_32.mak
.
The cause is that mkmake.c
somehow spits out a @rm whatever
in a section that does not
belong to a @ifdef VISUALC
section. I'm not sure if that's a bug in SLang or in my use of it (?).
But I'm merging this PR. Thanks again.
I've changed Makefile.all
to in use different behaviour for GNU make 3.x and 4.x. Commit: https://github.com/gvanem/Watt-32/commit/136e9daf99fec4fa87e9c5bce7a3551978ce33de
Hope this works for MacOS now.
That's a good idea, thanks. This solution kind of defeats the purpose of using a response file in the first place. Long command lines are likely not a problem on Mac, but djgpp and Windows should definitely use $(file)
.
In my djgpp build scripts I try to support MacOS. I don't have a Mac so I have to rely on running test builds via Github Actions...
Currently it fails to build Watt-32 due to:
This small patch makes it work.