Generated header files

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.dianegmail.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.waughgmail.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  -  jammingperforce.com
> >  http://maillist.perforce.com/mailman/listinfo/jamming
> >
> >
>
>
_______________________________________________
jamming mailing list  -  jammingperforce.com
http://maillist.perforce.com/mailman/listinfo/jamming

(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.dianegmail.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.waughgmail.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.dianegmail.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.waughgmail.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  -   jammingperforce.com
> > > >
> http://maillist.perforce.com/mailman/listinfo/jamming
> > > >
> > > >
> > >
> > >
> >
>
>
_______________________________________________
jamming mailing list  -  jammingperforce.com
http://maillist.perforce.com/mailman/listinfo/jamming

On 2007-07-12 at 02:43:07 [+0200], John Waugh
<john.waughgmail.com> wrote:
> (forgot to CC jamming)

(I wonder anyway why people use mail clients (respectively
settings) that by 
default don't just direct the reply to a mail from a mailing
list back to 
that list. And I personally find it quite useless to get the
same mail twice, 
when someone replies to one of my mails.)

Actually I don't quite understood your original problem, or
at least your 
analysis of it. As per documentation NoCare only causes a
target to be 
silently ignored which could not be found *and* has no
actions to create it. 
Whether NoCare is applied to your generated header should
not matter, should 
it?

I have to mention, that I use Matt Armstrong's header
caching patch (as 
everyone should), so this might not apply in the same way
for the unpatched 
jam: The only inconvenience I've encountered with respect to
generated 
headers, is when the header is included in a source file
compiled in a 
subdirectory different from that where the header was
generated. In such a 
case the grist automatically applied to the header name by
the header 
scanning process differs from the one used by the header
generating rule. Jam 
has to be told explicitely that a source file includes such
a header. E.g. 
"syscalls.c" including two header files generated
by an obscure rule in a 
completely different part of the directory tree:

Includes [ FGristFiles syscalls.c ]
    : <syscalls>syscall_dispatcher.h
<syscalls>syscall_table.h ;

> 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".

In my experience, it is not a good idea to have any path
components on 
targets other than directories and fixed files outside the
build system 
domain. Instead setting SEARCH/LOCATE on a target (and, if
necessary, add 
grist to make it unique) works just fine and has the
advantage of avoiding 
several kinds problems (e.g. MakeLocate not creating the
directory as 
expected, or accidental mismatching of target names by using
different but 
equally valid paths).

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

MakeLocate actually takes a target and a directory. You
probably mean 
something like "MakeLocate generated.h : [ FDirName
$(TOP) src ]". And yes, 
in general rules that generate a target should also locate
it.

> 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.

LOCATE has precedence. Then come the SEARCH paths, and last
the literal 
target name (without grist, of course).

CU, Ingo
_______________________________________________
jamming mailing list  -  jammingperforce.com
http://maillist.perforce.com/mailman/listinfo/jamming

On 7/13/07, Ingo Weinhold <bonefishcs.tu-berlin.de> wrote:
>
> (I wonder anyway why people use mail clients
(respectively settings) that by
> default don't just direct the reply to a mail from a
mailing list back to
> that list. And I personally find it quite useless to
get the same mail twice,
> when someone replies to one of my mails.)
>

Gmail isn't too nice on this point, it's true.
Unless there's a detect-mailing-list-and-reply-appropriately
option I
haven't found.
What client do  you use?

> Actually I don't quite understood your original
problem, or at least your
> analysis of it. As per documentation NoCare only causes
a target to be
> silently ignored which could not be found *and* has no
actions to create it.
> Whether NoCare is applied to your generated header
should not matter, should
> it?
>

Don't I feel dumb (: You're right, of course.
I confused myself with some leftover headers in the wrong
location
that were being detected as the desired ones (hence not
generating new
ones).

> I have to mention, that I use Matt Armstrong's header
caching patch (as
> everyone should), so this might not apply in the same
way for the unpatched
> jam: The only inconvenience I've encountered with
respect to generated
> headers, is when the header is included in a source
file compiled in a
> subdirectory different from that where the header was
generated. In such a
> case the grist automatically applied to the header name
by the header
> scanning process differs from the one used by the
header generating rule. Jam
> has to be told explicitely that a source file includes
such a header. E.g.
> "syscalls.c" including two header files
generated by an obscure rule in a
> completely different part of the directory tree:
>
> Includes [ FGristFiles syscalls.c ]
>     : <syscalls>syscall_dispatcher.h
<syscalls>syscall_table.h ;
>

Where can this patch be found, by the way? I searched the
archives and
googled a bit but didn't find it.
For the record, I'm using FTJam 2.5.2.

> > 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".
>
> In my experience, it is not a good idea to have any
path components on
> targets other than directories and fixed files outside
the build system
> domain. Instead setting SEARCH/LOCATE on a target (and,
if necessary, add
> grist to make it unique) works just fine and has the
advantage of avoiding
> several kinds problems (e.g. MakeLocate not creating
the directory as
> expected, or accidental mismatching of target names by
using different but
> equally valid paths).
>
> > Perhaps I just need to MakeLocate generated.h :
src/generated.h in my
> > Jamfile and pass the plain generated.h to my
rule?
>
> MakeLocate actually takes a target and a directory. You
probably mean
> something like "MakeLocate generated.h : [
FDirName $(TOP) src ]". And yes,
> in general rules that generate a target should also
locate it.
>

I'm trying to keep the user's Jamfile as simple as possible
- and by
user I mean the person using my GenerateHeaders rule.
Thus, I want them to be able to say something like:
    GenerateHeaders src/header0.h src/header1.h :
templatefile ;

As opposed to the more verbose (in each Jamfile that uses
GenerateHeaders):
    MakeLocate header0.h header1.h : [ FDirName $(SUBDIR)
src ] ;
    GenerateHeaders header0.h header1.h : templatefile ;

So I really want the targets of GenerateHeaders to be paths,
just for
convenience.
Inside GenerateHeaders, of course, I can strip off the path
from the
base filename and use header0.h and header1.h as the
"real" targets
for the actions, and set LOCATE as desired.
That's pretty much what I do at present.
However that still doesn't solve the problem of the filename
in the
#include not matching that target's name.
For instance, if one of these users wanted to do:
    GenerateHeaders some/crazy/dir/header.h : templatefile
;
And then it was #included as "crazy/dir/header.h",
maybe in some other
project far away, there seems to be no way to put 2 and 2
together
inside Jam. It doesn't affect me at present, but seems like
a
weakness.

Fundamentally, the files mentioned in #include are paths,
not Jam
targets, so it seems odd for Jam to treat them as such.
It almost seems like there should be a way to say "give
me all targets
that bind to filename X" and have HdrRule act on those,
rather than
just the target whose name exactly matches that of the
#include
statement.

> LOCATE has precedence. Then come the SEARCH paths, and
last the literal
> target name (without grist, of course).
>

Good to know, thanks.

-John
_______________________________________________
jamming mailing list  -  jammingperforce.com
http://maillist.perforce.com/mailman/listinfo/jamming