Header scanning change

From: Mark Sheppard (msheppard_at_[hidden])
Date: 2003-10-10 11:12:39

I've just been debugging a problem I had with header scanning failing.
Turned out I'd managed to delete the spaces from the regular expression
leaving just the tabs (doh!). But while I was debugging it and working out
what Jam was doing I made the following change so that the rule specified by
$(HDRRULE) gets the bound name of the source/header file:

--- boost-jam-3.1.4.orig/headers.c 2003-10-10 16:25:09.000000000 +0100
+++ boost-jam-3.1.4/headers.c 2003-10-10 16:09:07.000000000 +0100
@@ -86,7 +86,7 @@
{
FRAME frame[1];
frame_init( frame );
- lol_add( frame->args, list_new( L0, t->name ) );
+ lol_add( frame->args, list_new( L0, t->boundname ) );
#ifdef OPT_HEADER_CACHE_EXT
lol_add( frame->args, hcache( t, rec, re, hdrscan ) );
#else

This allows you to have something like this in your Jambase:

rule HdrRule ( source : headers + )
{
if $(SEARCH) {
SEARCH on $(headers) = $(source:D) $(SEARCH[2-]) ;
}
else {
SEARCH on $(headers) = $(source:D) $(INCPATH) ;
}

I never use SEARCH for finding sources - I guess this would need tweaking if
you do. Anyway my changes mean that Jam can now correctly find d.h in the
following case:

a.cpp:
#include "b/c.h"

b/c.h:
#include "d.h"

b/d.h:
whatever

Without this you'd have to explicitly add "b" to SEARCH somewhere. We've
got headers spread all over the place so that would make SEARCH very long
whereas INCPATH is relatively short.

Mark.