[jamming] Generated header files

[John Waugh]

On 7/13/07, Ingo Weinhold <bonefish at cs.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