make-w32
[Top][All Lists]
Advanced

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

Automatic prerequisite generation


From: Mike Capp
Subject: Automatic prerequisite generation
Date: Sun, 26 Jan 2003 02:15:52 +0000
User-agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.2.1) Gecko/20021130

I've been experimenting with running make in a standard Win98 DOS shell - yes, I know, I know. Call me a glutton for punishment, it's just that the MSYS shell seems too restrictive with regard to where you put your files, running make from editors and capturing the output, and so on.

The GNU MAKE manual section on "Generating Prerequisites Automatically" - at http://www.gnu.org/manual/make/html_chapter/make_4.html#SEC51 - suggests the following syntax for automatically generating .d from .c files:

%.d: %.c
    @set -e; rm -f $@; \
     $(CC) -M $(CPPFLAGS) $< > address@hidden; \
     sed 's,\($*\)\.o[ :]*,\1.o $@ : ,g' < address@hidden > $@; \
     rm -f address@hidden

While the above is a lot more portable than the old suggestion, it's still problematic in an environment as crippled as this. MSYS provides a sed, but DOS predictably doesn't appear to take much notice of the "set -e;".

Now, as far as I can see you'll only ever have one .o target in the generated .d, and it'll always be on the first line, so I wondered whether a more lightweight and portable way might be something as simple as:

%.d : %.c
    @echo $@ '\' > $@
    @$(CC) -M $(CPPFLAGS) $< >> $@

together with a .DELETE_ON_ERROR target to handle cleanup if something goes pear-shaped. A lot easier to read, and because there's no longer a dependency on sed it would become possible (albeit ugly) to write makefiles which only required MinGW and the standard DOS commands, not MSYS.

I've tried this out with MSYS make (from the 1.0.8 release) and the MinGW make (mingw32-make.exe from the 2.0 release), both based on GNU make 3.79.1, and it seems to work. However, I'm still a 'make' newbie, and suspect I'm missing something here. Are there problems with this approach I'm not seeing?







reply via email to

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