Paul's response is considerably better (as always!). I hadn't considered that side of the problem - my assumptions were incorrect.
If you are feeling particularly keen, another option which is reasonably complex but possible is a variation on the advanced makefiles described on Pauls website (http://make.paulandlesley.org/) - in this method you build so that the .o files end up in separate subdirectories. Personally, I like this but it isn't completely straight forward nor something worth doing for a single project. Regards, B. -----Original Message----- From: Paul D. Smith [mailto:[EMAIL PROTECTED] Sent: 25 February 2003 16:08 To: Andrea Riciputi Cc: Make Help Subject: Re: Make-ing different build. %% Andrea Riciputi <[EMAIL PROTECTED]> writes: ar> I need to write a makefile that allows me to build from basically ar> the same sources two different targets. The first is an ar> application (.exe file I mean), the latter is a library (.so ar> module). The rules for both the target are nearly the same, only ar> some compiler options change. ar> My intention was to write something like this: >> app.exe: $(fooObjectFiles) >> $(CCompiler) $(fooCFLAGS) $(fooLDFLAGS) $^ -o $@ >> >> %.o: %.c >> $(CCompiler) $(fooCFLAGS) -c $^ -o $@ >> >> .PHONY: bar >> >> bar: lib.so >> >> lib.so: $(barObjectFiles) >> $(CCompiler) $(barCFLAGS) $(barLDFLAGS) $^ -o $@ >> >> %.o: %.c >> $(CCompiler) $(barCFLAGS) -c $^ -o $@ You're missing an extremely important bit here: what are the definitions of fooObjectFiles and barObjectFiles? Given your comments above I'll assume that there is at least one file in common between these. That is your problem. ar> and call make in the following way: ar> % make foo // When I want to build app.exe ar> % make bar // When I want to build lib.so ar> However it doesn't work, because of the double %.o: %.c rule. That's not why it doesn't work. It may be technically why you get an error, but your problem is actually conceptual. It doesn't work because you are trying to create the same target using two different commands. That will not work with make. Make uses only timestamps to determine whether targets are out of date. So suppose you have a file foo.c which is shared between the library and the app. You run "make foo" and it compiles foo.c into foo.o with the app flags. Now you run "make bar". It sees that you need foo.o to link with the library. It looks on the disk. It sees a foo.o. It compares the timestamp to foo.c; foo.o is newer. So, it doesn't rebuild foo.o and now your library fails to build or work properly because the foo.o was compiled with the app flags and not the library flags. If you want to have the same source file compiled in different ways you _MUST_ use different output file as the target. Typically for shared libraries vs. applications the difference is that one is compiled as relocatable (with -fPIC or similar). Often what people do is use an extension of ".lo" for those objects, and keep the non-relocatable objects as .o. So, your makefile above becomes: >> app.exe: $(fooObjectFiles) >> $(CCompiler) $(fooCFLAGS) $(fooLDFLAGS) $^ -o $@ >> >> %.o: %.c >> $(CCompiler) $(fooCFLAGS) -c $^ -o $@ >> >> .PHONY: bar >> >> bar: lib.so >> >> lib.so: $(barObjectFiles) >> $(CCompiler) $(barCFLAGS) $(barLDFLAGS) $^ -o $@ >> >> %.lo: %.c >> $(CCompiler) $(barCFLAGS) -c $^ -o $@ and barObjectFiles contains values like "foo.lo bar.lo baz.lo" etc. -- ---------------------------------------------------------------------------- --- Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at: http://www.gnu.org http://make.paulandlesley.org "Please remain calm...I may be mad, but I am a professional." --Mad Scientist _______________________________________________ Help-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/help-make _______________________________________________ Help-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/help-make
