[Top][All Lists]

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

Re: Automatic prerequisite generation

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

Greg Chicares wrote:
Mike Capp wrote:

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.

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?

As you doubtless guessed, I think my objections largely stemmed from ignorance here. I'd heard that MSYS was purely an interactive shell, based on the assumption that you'd always be running 'make' from the supplied rxvt terminal, and the docs that came with it mostly reinforce that impression. This would make it pretty useless as an external tool for an editor. If, as seems to be the case, you can also run the sh.exe directly or specify it as the system shell inside your makefile, MSYS gets a *lot* more attractive.

And read this:

Have done, and am even beginning to understand it ;-) Seriously, the paper's great, it's just the sed commands that scare the bejesus out of me.

Looking at , several of the options look as if they're providing built-in support for the advanced idiom Paul describes. In particular...

[begin excerpt]
This option instructs CPP to add a phony target for each dependency other than the main file, causing each to depend on nothing. These dummy rules work around errors make gives if you remove header files without updating the Makefile to match.

    This is typical output:

test.o: test.c test.h

[end excerpt]

...which looks very much like Paul's "So, all we need to do is post-process the original dependency file and turn all the prerequisites into targets with no commands or prerequisites." Anyone have experience with this switch?

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

Hmm. I tried forcing various errors in the second command, and MAKE cleaned up properly every time, but I'll believe anything where COMMAND.COM is concerned...

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.

To clarify a couple of things ("|>" quoted lines are from your referenced post):

|> Use it to build this sed from source:

Is rolling your own sed still required? Even if you're using bash? The current MSYS already ships with GNU sed version 3.02, and I'd worry about a makefile that requires one particular build of one particular sed version to work properly.

|> # Changed 2001-12-03 by GWC: replaced single quote with double
|> # quote throughout. Required for win2k.

The sed command in your post uses single quotes throughout. Did you back the Windows-compatibility changes out when you switched to zsh? The comments look to predate your post by a fair ways.

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.

No, I was having the dependencies get built automatically using the remaking-makefiles feature. The GNU manual's recommendation is pretty much identical to Paul's paper up until the advanced section.

Many thanks for the tips and pointers; should keep me busy for a while :-)

reply via email to

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