Hi all,
At the moment our build environment is similar to the pseudo-makefile
listed below.
The commands to compile (~15 lines) are identical for APP1, and the same
holds for APP2, but each app uses different defines, compiler switches
etc. I'm trying to optimize these makefiles and reduce redundancy.
Is it possible to combine these compile rules into one/less for each
app? I checked the GNU make manual several times but I can't figure out
if it's possible to combine the rules. The only solution I could find
was to use "define" to create a "canned command sequence". I looked at
static pattern rules, and VPATH/vpath but the set of source directories
is (and must be) different between APP1 and APP2 so I can't see how that
would work.
Basically what I'm looking for is to tell GNU make that prerequisites
for _a particular_ output directory or target (i.e. app) can be found
there-and-so, preferably in one rule. The source files are just grouped
for logical or re-use purposes. This requires filenames to be unique for
a single app, I know; not sure if that's the best way to do things but
that's a separate issue. Right now I just want to minimize the makefile
content redundancy.
Our current build environment looks quite spiffy, IMHO, but I would
still like to get this right/optimal... I expect several people must
have run into this. Any tips?
Kind regards,
Joost Leeuwesteijn
--- makefile:
########################################################################
########
# PSEUDO MAKEFILE; listed as one file for better readability
########################################################################
########
#
# Directories:
# ------------
# .../make/
# /app1/
# /app2/
# .../src/
# /common/
# /mod1/
# /mod2/
# /lib/
# /app1/
# /sub1/
# /sub2/
# /app2/
# .../OUTPUT/ [ removed when doing a "make clean" ]
# /app1/
# /app2/
#
########################################################################
########
# In fact there's also a toplevel make-file and some included generic
makefiles
# that define several macros. Include directories (.h) have not been
mentioned.
########################################################################
########
# In fact this is in APP1.mk and included into the toplevel-makefile
$(APP1.OUTPUTDIR) := ../OUTPUT/APP1/
$(APP1.SOURCES) := common1.c lib.c mod1.c sub1.c sub2.c file1.c
file2.c file3.c
$(APP1.OBJECTS) := $(foreach f,$(basename
$(APP1.SOURCES)),$(APP1.OUTPUTDIR)/$(f).o)
$(APP1.OUTPUTDIR)/%.app : $(APP1.OBJECTS)
<commands to link>
$(APP1.OUTPUTDIR)/%.o : $(COMMON.COMMONDIR)/%.c
<commands to compile>
$(APP1.OUTPUTDIR)/%.o : $(APP1.MOD1DIR)/%.c
<commands to compile>
$(APP1.OUTPUTDIR)/%.o : $(APP1.LIBDIR)/%.c
<commands to compile>
$(APP1.OUTPUTDIR)/%.o : $(APP1.SUB1DIR)/%.c
<commands to compile>
$(APP1.OUTPUTDIR)/%.o : $(APP1.SUB2DIR)/%.c
<commands to compile>
$(APP1.OUTPUTDIR)/%.o : $(APP1.SOURCEDIR)/%.c
<commands to compile>
########################################################################
########
# In fact this is in APP2.mk and included into the toplevel-makefile
$(APP2.OUTPUTDIR) := ../OUTPUT/APP2/
$(APP2.SOURCES) := common1.c lib.c mod1.c mod2.c file1.c file2.c
file3.c
$(APP2.OBJECTS) := $(foreach f,$(basename
$(APP2.SOURCES)),$(APP2.OUTPUTDIR)/$(f).o)
$(APP2.OUTPUTDIR)/%.app : $(APP2.OBJECTS)
<commands to link>
$(APP2.OUTPUTDIR)/%.o : $(COMMON.COMMONDIR)/%.c
<commands to compile>
$(APP2.OUTPUTDIR)/%.o : $(APP2.MOD1DIR)/%.c
<commands to compile>
$(APP2.OUTPUTDIR)/%.o : $(APP2.MOD2DIR)/%.c
<commands to compile>
$(APP2.OUTPUTDIR)/%.o : $(APP2.LIBDIR)/%.c
<commands to compile>
$(APP2.OUTPUTDIR)/%.o : $(APP2.SOURCEDIR)/%.c
<commands to compile>
########################################################################
########
#
# Something like this would have been nice, unless I don't yet fully
understand
# the GNU make way to do this:
#
# $(APP1.OUTPUTDIR)/%.o : $(COMMON.COMMONDIR)/%.c $(APP1.SUB1DIR)/%.c
$(APP1.SOURCEDIR)/%.c etc
# <commands to compile>
#
# $(APP2.OUTPUTDIR)/%.o : $(COMMON.COMMONDIR)/%.c $(APP2.MODULE1DIR)/%.c
$(APP2.SOURCEDIR)/%.c etc
# <commands to compile>
#
# It also got me thinking if the original pseudo-makefile contents could
be generated by using some
# kind of smart function/define/eval/secondexpansion combination... (?)
# But native GNU make support would be my preference.
#
########################################################################
########
# END OF MAKEFILE
---
This communication contains confidential information. If you are not the
intended recipient please return this email to the sender and delete it from
your records.
Diese Nachricht enthält vertrauliche Informationen. Sollten Sie nicht der
beabsichtigte Empfänger dieser E-mail sein, senden Sie bitte diese an den
Absender zurück und löschen Sie die E-mail aus Ihrem System.
_______________________________________________
Help-make mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/help-make