[PATCH] Update backward/algo.h

[Nathan Myers]

On Wed, Jan 02, 2002 at 08:47:50PM +0100, Gabriel Dos Reis wrote:
> Nathan Myers <ncm-nospam@cantrip.org> writes:
> | I don't like seeing a carefully designed structure allowed to rot
> | just because nobody can be bothered to understand why it was built,
> | and then tearing it down because it was allowed to rot.
> | 
> | Gaby:
> | 
> | Do you have any reason to believe that src_dir != build_dir
> | protects against gmake deleting files in src_dir?
> 
>   When building the library with srcdir != builddir, the only thing
> we do in ${srcdir} is invoking autools to generate the files they need
> for creating Makefile.in and such.  That is all. In particular, make
> won't delete files it wants to.
> 
>   That said, I trust you that when you initially wrote the general
> guidelines,  you encountered some problems: I would like you give me a
> workable algorithm to reproduce those problems.  I think that may
> shed light on the issue.

After thinking and experimenting for a while, I found that the
easiest way to get current GNU make to delete my header went 
something like this; I don't remember if this is what happened 
back in 1998.

Suppose you have a file foo.cc that includes <foo>.  Suppose further 
that you have been experimenting with changes in header <foo>, so you 
have copied it into the local directory, and added "-I." to your 
CXXFLAGS to pick up your local version in place of the one off in 
src_dir.  Now, you mean to type "make foo.o", but you type "make foo" 
by accident. You get a foo.o all right, but then the link fails (no 
control-C needed) and make deletes the implicit target foo, which
happens also to be your header file.

This might seem a little far-fetched, but it's not meant as a use-case
to be supported, just an existence proof.  It's useful in the sense
that it elucidates the process and some of the prerequisites that lead
to make deleting files it oughtn't.

Foremost among these is Make's ".o.:" implicit rule, which is 
useless to us in any case (it invokes $(CC)).  Secondarily, file 
types distinguished not by naming convention, but by what directory 
they happen to be in, engender confusion both in people's expectations 
and in code written to those expectations.  Make cannot be told 
that files in certain directories are headers; it only understands 
suffixes.  Furthermore, sometimes we have good reasons to put files 
in other places, and a system that can't tolerate that is fragile.

The implicit rule problem should be easy to solve.  The naming
convention problem is a consequence of the failure to implement the 
preprocessor in the way the committee had expected, which was to 
alter suffixless header names before lookup.  The problem of make
deleting them is just one example of how our toolchain is ill-adapted
for suffixless sources.

It may be that recent changes in Make, coupled with great care in 
where files are edited, can substitute for a sound file naming 
convention.

Benjamin's example was troubling because he was claiming to have proved
a negative.  (An example of the form is a claim, "My system is secure,
I know because no one has broken in yet.")  Examples can only prove the
converse.

Eliminating all the bits/std_foo.h headers might be the right thing
to do, but we won't know all the problems they prevented until after 
they're gone.

Nathan Myers
ncm at cantrip dot org