[Top][All Lists]

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

Re: Automatic prerequisite generation

From: Greg Chicares
Subject: Re: Automatic prerequisite generation
Date: Sat, 25 Jan 2003 22:49:13 -0500

Mike Capp wrote:
> 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.

I spent frustrating years trying to get the
shells ms provides to do what I want, in
particular to work with *nix tools like make.
Then I just started using a native win32 port
of zsh, and I'd never go back. I use Amol
Deshpande's old zsh port--an unusual name like
that should make a web search easy if you're

I'm not sure I understand what you don't like
about MSYS, though (even though I prefer zsh
to bash, but you don't voice such a leaning)...

> too restrictive with regard to where you put your files

Just don't put them in one of the 'special'
MSYS directories.

> running make from editors and capturing the output

You can do
  make 2>&1 |less
  make some_target >/tmp/captured-output 2>&1
  make 2>&1 | tee captured-output
What do you want instead?

> and so on.

What other problems have you found?

> The GNU MAKE manual section on "Generating Prerequisites Automatically"
> - at -
> 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;".

Don't fight the environment--walk away from it.
Get a shell that works with stuff like this.
The ms shell is the problem.

And read this:

> 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) $< >> $@

You only need $(CPP) there. Of course $(CC)
calls it for you, but there may be some
overhead you could eliminate there. And
if you're doing this only for gcc (not
for any other compiler) you can use -MD
to avoid invoking the preprocessor twice.

> together with a .DELETE_ON_ERROR target to handle cleanup if something
> goes pear-shaped.

Even with that directive, I think it may
still be possible to get incomplete .d
files, if the first command works but the
second fails. I've seen weird things like
that happen.

> 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.

Here's a solution I developed when I was still
using ms shells:
This approach requires sed, but that message
tells how to make the perfect sed, using 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?

When do dependencies get built? If you have
to decide when to rebuild them, then you can
forget. And when you do decide, do they all
get rebuilt? These are the issues Paul's
white pater deals with.

reply via email to

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