Intersting feature (bug?) of bjam

From: c_andy_martin (c_andy_martin_at_[hidden])
Date: 2004-11-05 14:50:01

In my programming project, I have discovered an interesting "feature"
of bjam. I have created a sample project which demonstrates this
feature. Here is the output of `tree':
.
|-- Jamfile
|-- Jamrules
|-- boost-build.jam
|-- common
| |-- Jamfile
| |-- exception
| | |-- Exception.cpp
| | `-- Exception.h
| |-- test
| | |-- test.cpp
| | `-- test.h
| `-- xml
| |-- xml_a.cpp
| |-- xml_a.h
| |-- xml_b.cpp
| `-- xml_b.h
`-- main
|-- Jamfile
`-- main.cpp

Now, I have added <include>common to the Jamfiles, so that I can write:
#include "test/test.h"
from main.cpp and from test.cpp, etc.

The project builds normally. Everything works. Now we do something
that should normally have no effect on rebuilding:
cd project_root; touch common/exception/

However, because common/exception/Exception.h has this line:
#include <exception>
bjam thinks that the standard include <exception> was updated, so all
of its dependencies must be updated (since it confused the directory
`exception' with the standard include file <exception>!).

This is really frustrating because using commands like `vi
common/exception/Exception.h' causes the timestamp on the directory
`common/exception' to be udpated (because of swap file creation) so
bjam interprets this as the standard include <exception> being out of
date, forcing to rebuild almost the entire project which makes
programming very difficult.

My actual project is much, much larger than this and moving files
around and renaming things at this point to get around the conflict
would be inconvinient. Note that parts of the boost distribution would
have had this problem if instead of <include>$(BOOST_ROOT) was used,
<include>$(BOOST_ROOT)/boost and code used #include
<utility/result_of.hpp> in place of #include
<boost/utility/result_of.hpp> and the standard header #include
<utility> was used as well. I suppose I could go through all my code
and translate include files like <exception/Exception.h> into
<common/exception/Exception.h> and that would fix things.

Is there any easy way to work around this other than renaming
directories which match standard include files (such as <exception>,
<string>, <utility>, <algorithm>, etc.)? I guess one way might be to
somehow modify the search path so that bjam finds the standard
exception include before the directory common/exception.

Thanks for any help,
-Andy