gzdoom-gles/tools/makewad/Makefile

ifeq (Windows_NT,$(OS))
  EXE = makewad.exe
  CCDV = @../../ccdv
  CFLAGS = -Os -Wall -fomit-frame-pointer
  LDFLAGS = -L../../zlib/ -lz
  ZLIB = ../../zlib/libz.a
else
  EXE = makewad
  CCDV = 
  CFLAGS = -Dstricmp=strcasecmp -Dstrnicmp=strncasecmp -Os -Wall -fomit-frame-pointer
  LDFLAGS = -lz
  ZLIB =
endif

CC = gcc

OBJS = makewad.o ioapi.o zip.o

all: $(EXE)

.c.o:
	$(CCDV) $(CC) $(CFLAGS) -c -o $@ $<

$(EXE): $(OBJS) $(ZLIB)
	$(CCDV) $(CC) -o $(EXE) $(OBJS) $(LDFLAGS)

ifeq (Windows_NT,$(OS))
$(ZLIB):
	make -C ../../zlib -f Makefile.mgw
endif

.PHONY: clean

clean:
ifeq (Windows_NT,$(OS))
	-del /q /f $(EXE) 2>nul
	-del /q /f *.o 2>nul
else
	-rm -f $(EXE)
	-rm -f *.o
endif
GCC fixes: (courtesy of Jim and zloba) - default.cbd was missing thingdef_exp.cpp - tools/makewad/Makefile.mgw was outdated thanks to recently added zip support - wadsrc/wadmake should not be in the repository, as it needs to use host machine path separator conventions SVN r69 (trunk) 2006-04-29 04:52:30 +00:00			`ifeq (Windows_NT,$(OS))`
			`EXE = makewad.exe`
			`CCDV = @../../ccdv`
			`CFLAGS = -Os -Wall -fomit-frame-pointer`
			`LDFLAGS = -L../../zlib/ -lz`
- Fixed: CopyPlayer() in p_saveg.cpp should use normal assignment, not memcpy to copy the player structures. - Fixed compilation with MinGW again and removed most of the new warnings. And following is the log that I forgot to paste in for the previous commit: - Changed the memory management for FString. Instead of using a garbage collected heap, it now uses normal heap calls and reference counting to implement lazy copying. You may now use bitwise operators to move (but not copy!) FStrings around in memory. This means that the CopyForTArray template function is gone, since TArrays can now freely move their contents around without bothering with their specifics. There is one important caveat, however. It is not acceptable to blindly 0 an FString's contents. This necessitated the creation of a proper constructor for player_s so that it can be reset without using memset. I did a quick scan of all memsets in the source and didn't see anything else with a similar problem, but it's possible I missed something. - Fixed: Build tiles were never deallocated. - Fixed: Using Build's palette.dat only got half the palette right. SVN r117 (trunk) 2006-05-16 04:19:20 +00:00			`ZLIB = ../../zlib/libz.a`
GCC fixes: (courtesy of Jim and zloba) - default.cbd was missing thingdef_exp.cpp - tools/makewad/Makefile.mgw was outdated thanks to recently added zip support - wadsrc/wadmake should not be in the repository, as it needs to use host machine path separator conventions SVN r69 (trunk) 2006-04-29 04:52:30 +00:00			`else`
			`EXE = makewad`
			`CCDV =`
			`CFLAGS = -Dstricmp=strcasecmp -Dstrnicmp=strncasecmp -Os -Wall -fomit-frame-pointer`
			`LDFLAGS = -lz`
- Fixed: CopyPlayer() in p_saveg.cpp should use normal assignment, not memcpy to copy the player structures. - Fixed compilation with MinGW again and removed most of the new warnings. And following is the log that I forgot to paste in for the previous commit: - Changed the memory management for FString. Instead of using a garbage collected heap, it now uses normal heap calls and reference counting to implement lazy copying. You may now use bitwise operators to move (but not copy!) FStrings around in memory. This means that the CopyForTArray template function is gone, since TArrays can now freely move their contents around without bothering with their specifics. There is one important caveat, however. It is not acceptable to blindly 0 an FString's contents. This necessitated the creation of a proper constructor for player_s so that it can be reset without using memset. I did a quick scan of all memsets in the source and didn't see anything else with a similar problem, but it's possible I missed something. - Fixed: Build tiles were never deallocated. - Fixed: Using Build's palette.dat only got half the palette right. SVN r117 (trunk) 2006-05-16 04:19:20 +00:00			`ZLIB =`
GCC fixes: (courtesy of Jim and zloba) - default.cbd was missing thingdef_exp.cpp - tools/makewad/Makefile.mgw was outdated thanks to recently added zip support - wadsrc/wadmake should not be in the repository, as it needs to use host machine path separator conventions SVN r69 (trunk) 2006-04-29 04:52:30 +00:00			`endif`
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk) 2006-02-24 04:48:15 +00:00
			`CC = gcc`

GCC fixes: (courtesy of Jim and zloba) - default.cbd was missing thingdef_exp.cpp - tools/makewad/Makefile.mgw was outdated thanks to recently added zip support - wadsrc/wadmake should not be in the repository, as it needs to use host machine path separator conventions SVN r69 (trunk) 2006-04-29 04:52:30 +00:00			`OBJS = makewad.o ioapi.o zip.o`
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk) 2006-02-24 04:48:15 +00:00
			`all: $(EXE)`

			`.c.o:`
			`$(CCDV) $(CC) $(CFLAGS) -c -o $@ $<`

- Fixed: CopyPlayer() in p_saveg.cpp should use normal assignment, not memcpy to copy the player structures. - Fixed compilation with MinGW again and removed most of the new warnings. And following is the log that I forgot to paste in for the previous commit: - Changed the memory management for FString. Instead of using a garbage collected heap, it now uses normal heap calls and reference counting to implement lazy copying. You may now use bitwise operators to move (but not copy!) FStrings around in memory. This means that the CopyForTArray template function is gone, since TArrays can now freely move their contents around without bothering with their specifics. There is one important caveat, however. It is not acceptable to blindly 0 an FString's contents. This necessitated the creation of a proper constructor for player_s so that it can be reset without using memset. I did a quick scan of all memsets in the source and didn't see anything else with a similar problem, but it's possible I missed something. - Fixed: Build tiles were never deallocated. - Fixed: Using Build's palette.dat only got half the palette right. SVN r117 (trunk) 2006-05-16 04:19:20 +00:00			`$(EXE): $(OBJS) $(ZLIB)`
			`$(CCDV) $(CC) -o $(EXE) $(OBJS) $(LDFLAGS)`

			`ifeq (Windows_NT,$(OS))`
			`$(ZLIB):`
			`make -C ../../zlib -f Makefile.mgw`
			`endif`
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk) 2006-02-24 04:48:15 +00:00
			`.PHONY: clean`

			`clean:`
GCC fixes: (courtesy of Jim and zloba) - default.cbd was missing thingdef_exp.cpp - tools/makewad/Makefile.mgw was outdated thanks to recently added zip support - wadsrc/wadmake should not be in the repository, as it needs to use host machine path separator conventions SVN r69 (trunk) 2006-04-29 04:52:30 +00:00			`ifeq (Windows_NT,$(OS))`
Directory restructuring to make it easier to version projects that don't build zdoom.exe. SVN r4 (trunk) 2006-02-24 04:48:15 +00:00			`-del /q /f $(EXE) 2>nul`
			`-del /q /f *.o 2>nul`
GCC fixes: (courtesy of Jim and zloba) - default.cbd was missing thingdef_exp.cpp - tools/makewad/Makefile.mgw was outdated thanks to recently added zip support - wadsrc/wadmake should not be in the repository, as it needs to use host machine path separator conventions SVN r69 (trunk) 2006-04-29 04:52:30 +00:00			`else`
			`-rm -f $(EXE)`
			`-rm -f *.o`
			`endif`