3 messages in com.perforce.jamming[jamming] Is there a bug in Header fi...
FromSent OnAttachments
Koloseike10 Mar 2000 07:58 
Dian...@yahoo.com10 Mar 2000 10:22 
Matt...@corp.phone.com10 Mar 2000 22:45 
Subject:[jamming] Is there a bug in Header file dependencies?
From:Koloseike (@)
Date:03/10/2000 07:58:26 AM
List:com.perforce.jamming

I've settled on using fully qualified target names with rooted directories. Everything seems to be working well, but there is one fly in the ointment

The situation is as follows:

- Jamfile #1 uses the SubInclude rule to include Jamfiles #2 and #3.

- Jamfile #2 uses a custom rule to generate a Header and a C++ file, based on some text files. This rule also associates the generated files with the 'files' pseudo target.

- Jamfile #3 builds a library from several static C++ files and the generated C++ file in Jamfile #2. Some of the static C++ files also include the Header file generated in Jamfile #2.

If I force Jamfile #2 to regenerate the C++ and header file by touching one or more of their dependent text files ...

Jamfile #3 sees that the generated C++ file has been updated, so Jam compiles and sticks in the library. For some reason Jam fails to realize the static C++ files, dependent on the generated Header file also need to be recompiled.

If I run Jam a second time it finally clues in and realizes that some of static C++ files need to be recompiled.

Why is this happening. I don't want to have start writing complex header file dependency trees. The automatically handling of the chore was one of the major reasons we picked Jam. It also defeats the purpose of SubInclude and treating all the Jam files as one.

I've tried adding the generated files to the 'first' pseudo target instead, but this doesn't help.

Any suggestion? I'm currently running Jam 2.2.1 on Linux.