[jamming] generated header

Vladimir Prus ghost at cs.msu.su
Mon Nov 22 00:10:53 PST 2004


On Saturday 20 November 2004 20:54, you wrote:
> --- Vladimir Prus <ghost at cs.msu.su> wrote:
> > On Friday 19 November 2004 23:26, Diane Holt wrote:
> > > I get regular Jam to do the right things with generated headers --
> > > just make sure that a) the header target matches what appears in the
> > > #include, and
> >
> > Could you clarify this? You mean, grist of header target should be the
> > same as grist added by HdrRule?
>
> No -- I mean I specifically exclude generated-header targets from getting
> grist set on them, 

This looks like a showstopper for Boost.Build -- we need to set grist on 
anything, because if you're building both debug and release versions at the 
same time, the targets for both version should be placed to different 
directories

> so that the target looks exactly like what HdrRule 
> found in its scan -- eg., support/Foo.h is what the scan turns up (and so
> takes care of the Includes association for me between that header and
> whatever source-file(s) it found it in), 
> and support/Foo.h is what that 
> header target is, 

What if I happen to have two "support/Foo.h" files? Or, more realistically, 
two files wisely named "parser.h"? 

> or if it's not, then the rule that deals with that 
> header target does an Includes on that form of the target (ie., if it's a
> type of generated header that's passed to the actions as just Foo.h, its
> rule will associate it to support/Foo.h, the "support" part of which it
> knows about in some way -- eg., where in the tree the target is coming
> from, or some additional parameter, etc.)

I'm sorry, I could not understand the above.

> > > b) you change HdrRule to not hang a NoCare on it.
> >
> > And what about system headers? Jam would complain about not finding
> > them, unless I add system directories to jams search path, and those
> > directories vary from system to system.
>
> No, I mean I specifically exclude the generated header targets from
> getting NoCare put on them -- all the rest of the headers the HdrRule scan
> turns up still get it put on them. Any rule of mine that deals with
> generated headers adds the header target (in the correct form that HdrRule
> will find it in in its scan) to a var (which I call NO_HDRGRIST, logically
> enough :)  My override of HdrRule checks for the header being in
> NO_HDRGRIST, and if it's in there, then no grist is added to it, nor does
> the NoCare get put on it.

In addition to the issues above, this might be too explicit. In Boost.Build, 
user would write:

  generators.register something.generate-parser : P : CPP HPP ;
  actions generate-parser
  {
 parser $(<) -p $(>)
  }

which means that file of type 'P' can be converted to CPP/HPP combination with 
the specified action. Now, if user is required to set NO_HDRGRIST...... I 
don't even know how to document this without getting very deep in Jam 
internals.

- Volodya
 







More information about the jamming mailing list