help-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: How to reduce makefile redundancy?


From: Leeuwesteijn, Joost
Subject: RE: How to reduce makefile redundancy?
Date: Mon, 19 Nov 2007 15:00:22 +0100

 

dmake seems to have implemented this using a pipe symbol,
see http://tools.openoffice.org/dmake/dmake_4.11.html (search on '%.o :|
%.c %.r %.f ; some rule', without quotes).

Does GNU make support a similar construct (don't think so after reading
the manual)?

--
Joost



> -----Original Message-----
> From: Leeuwesteijn, Joost
> Sent: maandag 19 november 2007 14:47
> To: address@hidden
> Subject: How to reduce makefile redundancy?
> 
> 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
> 
> 
> 
> ---
> 
> _______________________________________________
> Help-make mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/help-make
> 


---

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]