Richard Russell wrote: ↑Wed Sep 12, 2018 6:42 pm
I know nothing about 'GNU autotools' (and I note that davidb says that makefiles should be written by hand)...
David said "if they are written by hand". It is generally seen as best practice to put in the repository the files that are the result of your own manual work and leave out those that are machine-generated from other files you did generate by hand. So, in the case of GNU autotools there is a Makefile.am which is generated by hand which gets turned into a Makefile by automake so I add Makefile.am to the repository and not Makefile. Makefile.win is generated by hand so that is in the repository.
I am not suggesting, either, that you dive into GNU autotools. It solves a particular problem in resolving differences for the many Unix-family operating systems and is therefore supposed to save the complexity of doing this yourself but it is, itself, quite complicated and therefore a significant effort to learn.
Richard Russell wrote: ↑Wed Sep 12, 2018 6:42 pm
As far as each platform's build including "the right set of modules" is concerned, how is that actually achieved?
A Makefile has rules to say what goes into each program being built so you only include the modules you need in the rule and the other are ignored. As an example, here is Makefile.win from B-Em:
Code: Select all
VPATH = . resid-fp NS32016 darm
CPP = i686-w64-mingw32-g++
CC = i686-w64-mingw32-gcc
WINDRES = windres.exe
# The following flags are used by PiTubeDirect Co Pros:
# BEM - fixes for compilation in B-Em envorinment
# INCLUDE_DEBUGGER - include the cpu_debug implementation
# USE_MEMORY_POINTER - do not assume Co Pro memory starts at address 0
COMMON_FLAGS = -O3 -Wall -I ../../allegro5/include -DBEM -DVERSION=\"Win32\" -DINCLUDE_DEBUGGER -DUSE_MEMORY_POINTER
CFLAGS = -std=gnu99 $(COMMON_FLAGS)
CXXFLAGS = $(COMMON_FLAGS)
OBJ = \
6502.o \
6502debug.o \
6502tube.o \
65816.o \
acia.o \
adc.o \
arm.o \
darm.o \
darm-tbl.o \
armv7.o \
armv7-tbl.o \
thumb.o \
thumb-tbl.o \
thumb2.o \
thumb2-decoder.o \
thumb2-tbl.o \
cmos.o \
compact_joystick.o \
compactcmos.o \
compat_wrappers.o \
config.o \
csw.o \
ddnoise.o \
debugger.o \
disc.o \
fdi2raw.o \
fdi.o \
gui-allegro.o \
i8271.o \
ide.o \
joystick.o\
keyboard.o \
keydef-allegro.o \
logging.o \
main.o \
mem.o \
midi-windows.o \
model.o \
mouse.o \
music2000.o \
music4000.o \
music5000.o \
pal.o \
savestate.o \
scsi.o \
sdf.o \
serial.o \
sn76489.o \
sound.o \
sysacia.o \
sysvia.o \
tape.o \
tapecat-allegro.o \
tapenoise.o \
tsearch.o \
tube.o \
uef.o \
uservia.o \
vdfs.o \
via.o \
vidalleg.o \
video.o \
wd1770.o \
win.o \
x86.o \
x86dasm.o \
z80.o \
z80dis.o \
resid.o \
b-em.res
NS32KOBJ = \
32016.o \
32016_debug.o \
Decode.o \
mem32016.o \
Trap.o \
Profile.o \
NSDis.o
SIDOBJ = \
convolve.o \
envelope.o \
extfilt.o \
filter.o \
pot.o \
sid.o \
voice.o \
wave6581__ST.o \
wave6581_P_T.o \
wave6581_PS_.o \
wave6581_PST.o \
wave8580__ST.o \
wave8580_P_T.o \
wave8580_PS_.o \
wave8580_PST.o \
wave.o
LIBS = -L ../../allegro5/lib -lz -lallegro_audio -lallegro_acodec -lallegro_primitives -lallegro_dialog -lallegro_image -lallegro_font -lallegro -mwindows -lgdi32 -lwinmm -lstdc++
all : b-em.exe hdfmt.exe
b-em.exe: $(OBJ) $(SIDOBJ) $(NS32KOBJ)
$(CC) $(OBJ) $(SIDOBJ) $(NS32KOBJ) -o "b-em.exe" $(LIBS)
clean :
del *.o *.exe *.res
%.o : %.c
$(CC) $(CFLAGS) -c $<
%.o : %.cc
$(CPP) $(CXXFLAGS) -c $<
b-em.res: b-em.rc
$(WINDRES) -i b-em.rc --input-format=rc -o b-em.res -O coff
hdfmt.exe: hdfmt.c
$(CC) $(CFLAGS) -o hdfmt.exe hdfmt.c
Three variables, OBJ, NS32KOBJ and SIDOBJ are each set to lists of modules and the lines:
Code: Select all
b-em.exe: $(OBJ) $(SIDOBJ) $(NS32KOBJ)
$(CC) $(OBJ) $(SIDOBJ) $(NS32KOBJ) -o "b-em.exe" $(LIBS)
Tell make to link that set of object files into the b-em.exe excutable and other rules tell make how to generate those object files from their corresponding source files by running the compiler on them. As the file linux.o (compiled from linux.c) containing linux-specific code doesn't appear in any of those variables it doesn't get compiled or linked when building for Windows.
Note also that this Makefile uses VPATH because there are some modules that have been imported into B-Em from elsewhere each of which lives in a sub-directory, but which are linked into B-Em directly, not built into a separate library.
What I cannot advise on is how to use Visual Studio or one of the mobile phone devlopment IDEs to add/remove from the set of files that will be compiled and linked as part of the project, though I hope that is possible.
Richard Russell wrote: ↑Wed Sep 12, 2018 6:42 pm
... I've had a quick look at the SDL build process and that first copies the wanted source files into a platform-specific directory; is that a good method?
There is nothing wrong with that as long as the copying is automated as part of the built process. What I think you want to avoid is having to maintain multiple copies of the same file in different directories. If you work on, and have checked into the repository, a single copy of each source file it doesn't matter if the build process takes temporary copies as part of that process. It may not be as efficient as simply referring to the shared copy (VPATH etc.) but, as long as you are not tempted to edit the temporary copies, it shouldn't result in a muddle.