[jamming] Generated header files

[John Waugh]

(forgot to CC jamming)

I don't have my files with me, but I believe the directory structure
is something like this:

-myproject
--src
---main.cpp
---generated.h
--Jamfile

Then in the Jamfile, I pass "src/generated.h" to my GenerateHeader
rule, so it knows where to create it. But in main.cpp, I have a plain
#include "generated.h".

Perhaps I just need to MakeLocate generated.h : src/generated.h in my
Jamfile and pass the plain generated.h to my rule?

if both LOCATE and SEARCH are set on a target, does LOCATE take
priority? I think HdrRule sets SEARCH, so if I have both on there I'm
not sure what happens.
Though of course, I could exclude those files from having SEARCH set
on them using your previous suggestion.

-John

On 7/11/07, Diane Holt <holt.diane at gmail.com> wrote:
> You should have the targets match the includes. Why do your generated
> headers have "include/" in there?
>
>
> Diane
>
> On 7/11/07, John Waugh < john.waugh at gmail.com> wrote:
> > Ah I remember seeing that somewhere ages ago and had forgot - thanks!
> >
> > Since that worked out well - here's more questions (:
> >
> > Is there any way to make sure the names of the .h files referenced in
> > the Jamfile "match up" with those detected during header scanning?
> >
> > Essentially, I want a way to detect if (possibly) multiple targets in
> > fact bind to the same concrete file.
> >
> > The reason being that I want to (in my GenerateHeaders rule) say:
> >    Includes $(header_files) : $(template_files) ;
> >
> > Where template_files are the files from which the header_files are
> generated.
> > That way if template_files change, the headers get regenerated and the
> > appropriate sources get recompiled.
> >
> > The problem is in the case where header files that GenerateHeaders
> > knows about look like "include/foo.h", but the ones #included in the
> > .cpp files look like "foo.h".
> >
> > Currently, if they don't match up, header_files aren't in the
> > dependency tree and jam doesn't even see them.
> >
> >
> > Thanks
> > -John
> >
> > On 7/11/07, Diane Holt <holt.diane at gmail.com> wrote:
> > > I distinguish generated headers by including them in a var (called
> NO_HDRGRIST, but I suppose GENHDR or some such would have been better :)
> then exclude the files listed in that var from the NoCare (and from getting
> gristed with HDRGRIST, which explains the name a bit :)
> > >
> > > Diane
> > >
> > >
> > >
> > > On 7/11/07, John Waugh <john.waugh at gmail.com> wrote:
> > > >
> > > >  I have a rule that calls a script which generates some .h files,
> which are included by other .cpp files.
> > > >
> > > > This works fine for the most part, except when the .h files need to be
> generated freshly.
> > > > Jam's header scanning applies NoCare to the headers, so if the .h
> files don't exist, jam doesn't cause them to be generated.
> > > >
> > > > Any way around this?
> > > > There's no "UnNoCare" rule, I presume (:
> > > >
> > > > Of course I can also have some special target such as 'generate' which
> will just force the files to be created, but ideally a user would just have
> to build the main project, which will cause the headers to be generated as
> needed.
> > > >
> > > > Tips?
> > > >
> > > > -John
> > > >
> > > >
> > > > _______________________________________________
> > > > jamming mailing list  -   jamming at perforce.com
> > > >
> http://maillist.perforce.com/mailman/listinfo/jamming
> > > >
> > > >
> > >
> > >
> >
>
>