Details on unwanted generated header dependancies

This is with Jam 2.5rc3 on Windows 2000.

I was told that the "independant target" warnings might be a problem, so 
here's everything.

Jamrules
========
rule
LaHeaderLocal
{
        local   var ;

        for var in $(<)
        {
                LawMkHdr $(var:B).h : $(var:B).c : -l ;
        }
}

rule
LawMkHdr
{
        local   source ;

        source = [ FGristSourceFiles $(>) ] ;
        Depends files : $(<) ;
        Depends $(<) : $(source) ;
        Clean clean : $(<) ;
        SEARCH on $(source) = $(SEARCH_SOURCE) ;
        MakeLocate $(<) : $(LOCATE_SOURCE) ;
        MKHDRFLAG on $(<) = $(3) ;

Bison, Flex, G++ project problem.

Bison, Flex, G++ project problem

To start out with I have to admit I am pretty new at Jam.  I
have simplified my build process for 4 source trees in the
last couple of days with Jam but by no means am I an expert
and I haven't even had to write any of my own rules yet.

IN truth if I had to write my own rule I might be lost since
I can't even find where the 2.5 rpm I used to instal jam hid
my Jambase file.

So now to my question.

I have a compiler that has 14 .cpp files and 2.y files and
2.l files.  I tried to make just a MAIN statement to do them
all at once but it failed on the .y and .l files and after
looking at the makefile I can understand why.  The following
is the shortened version of the makefile I need to convert.

vmcpar.cpp:	vmcpar.y
YFLAG = -d -y -v 
bison --debug $(YFLAG) vmcpar.y
	 <at> -if [ -f y.output ]; then mv y.output ../platform/$(PLATFORM)/vmc/tmp_vmcpar.output; fi
	 <at> mv y.tab.c ../platform/$(PLATFORM)/vmc/tmp_vmcpar.cpp
	 <at> mv y.tab.h ../platform/$(PLATFORM)/vmc/tmp_vmcpar.h

vmclex.cpp:	vmclex.l
	flex -t vmclex.l $(LEXFILTER) > ../platform/$(PLATFORM)/vmc/tmp_vmclex.cpp

dilpar.cpp: dilpar.y
	bison --debug -d -v -pdil dilpar.y
	 <at> -if [ -f dilpar.output ]; then mv dilpar.output ../platform/$(PLATFORM)/vmc/tmp_dilpar.output; fi

RE: Making different library versions

Hello,

> 
> Forget about grist, ObjectC++Flags and LibraryFromObjects. 
> You could make your
> life much easier with a little trick involving local variables:
> 
> # Have a library of core files that actually have a cpp file.
> for size in $(SIZES) 
> {
>   # define local variable, whose value is the global C++FLAGS 
> plus additionnal
>   # flags that will be used by Library and other rules called by it
>   #
>   local C++FLAGS = $(C++FLAGS) -DBWIDTH=$(size) -DBHEIGHT=$(size) ;
> 
>   Library  core_lib_$(size) : assertion.cpp ;
> }
> 

Sorry, I was wrong, this will not work because the same source file
is used as a source, and the Library rule will not distinguish between
the two distinct resulting objects..

> Another excellent use of Jam's dynamic variable scoping. This works
> also extremely well to temporarily change the include path
> (local HDRS = $(HDRS) <yourotherpaths> ;) and many more options.
> 

Well, Jam's dynamic scoping can be very useful, but not in this

blah.y depends on itself

Hi,

I have a .y file which includes its own y.tab.h. Jam complains that the 
.y file depends on itself, which seems wrong. I hacked that by setting 
HDRSCAN to null on the file in question.

But the deeper question remains. How to fix that?

The .y file doesn't depend on that which it includes. The .c which is 
built from that .y does, and I don't see any way to express that in 
Jam. Does any of you?

--Arnt

Re: blah.y depends on itself

On Thu, Dec 04, 2003 at 07:13:09PM +0100, Arnt Gulbrandsen wrote:
> I have a .y file which includes its own y.tab.h. Jam complains that the 
> .y file depends on itself, which seems wrong. I hacked that by setting 
> HDRSCAN to null on the file in question.

Yes, it's very annoying. 

> But the deeper question remains. How to fix that?
> 
> The .y file doesn't depend on that which it includes. The .c which is 
> built from that .y does, and I don't see any way to express that in 
> Jam. Does any of you?

I think the relationships are expressed OK here.  It's the warning
that's at fault.

The case that first bit me was running "cproto" to automatically
generate a C-function-prototype file, which was then included at 
the top of the source file.  Same warning message.

So I think in your case, the ".c" stage is not the issue.  Yes, it
exists, but so does next stage ".o" file.  Equivalently, if you
imagined you had a direct .y -> .o compiler, you still hit the
same problem.  Jam believes that if you #include generated code
back into its source, you have a circular build dependency.

And that's wrong.  Clearly the .y file doesn't depend
on _anything_.  It just _is_.  It's source.

Why this is happening, as far as I can tell, is that jam "inclusion"

Re: blah.y depends on itself

I have found them useful when writing rules that do a lot of a->b->c->d 
type of stuff.  On occasion we have intermediate programs which get 
built to parse things or generate generators.  The kind of stuff where 
Jam really shines for readability and maintenance of a complex build 
process.

This means that while there is an a->b->c->d, the actual dependencies 
aren't that straight forward, since b would provide for more things 
than c, and c for more things than d, etc..  When interpreted as a 
sequence of steps, like what a sequential script would do, things would 
seem to work out OK.  However, you could (and with 'make' I frequently 
did) run into situations where a, b or c gets updated and the rules 
don't specify they really all do depend on each other.  Without 
realizing why you have an incremental build which really isn't properly 
updated.

The other big reason to have a dependency graph which properly connects 
all the dangling pieces is for parallel builds (-j) to work properly.

So on more than one occasion for me this warning has saved me.

On Dec 7, 2003, at 7:15 PM, Anthony Heading wrote:

> Having done that, I'm now scratching my head about why so-called
> "independent targets" are regarded as evil.  Can anyone explain
> why these justify a warning, or why the default Jambase file even
> describes them as "deadly"?  Otherwise, that might be the next
> warning that I remove!

Re: blah.y depends on itself

I see the bug. If a depends on b, which includes c, which depends on a, 
then the "except for includes" logic in make.c near line 275 breaks for 
a, since the intervening includes isn't visible.

I changed the code, but I'm not sure whether the change is sound... will 
test it when I get back to my Jamfile. A better way might be to add 
another argument to make0(), saying whether this part of the graph is 
coloured by an include.

 <at>  <at>  -152,6 +152,8  <at>  <at> 
         return status;
  }

+static int including;
+
  /*
   * make0() - bind and scan everything to make a TARGET
   *
 <at>  <at>  -272,10 +274,16  <at>  <at> 
             /* Warn about circular deps, except for includes, */
             /* which include each other alot. */

+           if ( internal )
+               including++;
+
             if( c->target->fate == T_FATE_INIT )
                 make0( c->target, ptime, depth + 1, counts, anyhow );
-           else if( c->target->fate == T_FATE_MAKING && !internal )
+           else if( c->target->fate == T_FATE_MAKING && !including )
                 printf( "warning: %s depends on itself\n", c->target->name );

NoUpdateDependents

I recently had an issue with building shared libraries.  (For the
remainder of this email, I will use library to mean *shared*
libraries.)

Basically, targets really need to depend on their libraries, or they
might not be created.  However, if targets do depend on libraries,
whenever the libraries are rebuilt, so are the targets that depend
upon them.  This is non-ideal, since in many cases, the libraries are
linked with many programs, causing a whole cascade of relinking.  The
only instance where you would wish to rebuilt the targets is when the
library's ABIs change.

Invoking NOUPDATE on the libraries doesn't help, since the libraries
are never changed once first built.  I have seen workarounds on the
list to deal with this problem, but what is really needed is a flag to
disconnect the library dependencies from the targets that use them.

Now, there may be such changes in the very latest version of jam (I am
running 2.5rc3 which the website claims is current), so what follows
may well duplicate work I haven't seen, but....

I have attached a short patch.  By invoking the "NoUpdateDependents"
rule on a library, changes to that library will not be propagated up
the dependency tree.  It works simply by skipping over dependencies if
both target and library exist (and the appropriate flag is set).

Hope it is helpful.

Cheers,
Matt

Re: blah.y depends on itself

| I see the bug. If a depends on b, which includes c, which depends on a, 
| then the "except for includes" logic in make.c near line 275 breaks for 
| a, since the intervening includes isn't visible.

Actually, if you use jam -dd you'll see that there is indeed a circular
dependency listed.  In this case:

	Includes blah.y : blah.h ;
	Depends blah.h : blah.y ;

That is to say, to generate anything from blah.y you need the text of
blah.h as well, yet blah.h depends on blah.y.  Jam is correct in issuing
the warning.

What's wrong is the Yacc rule in the Jambase, which allows the header
scan operation to attribute blah.h to blah.y rather than the generated
blah.c.  The fact is if blah.y has a #include in it, it is blah.c that
actually needs the "Includes" dependency.

Here's a Jambase diff:

*** /tmp/tmp.93249.0	Mon Dec  8 14:24:42 2003
--- /usr/big/seiwald/jam/Jambase	Mon Dec  8 14:05:43 2003
***************
*** 37,42 ****
--- 37,43 ----
  # 11/21/96 (peterk) - Support for BeOS
  # 07/19/99 (sickel) - Support for Mac OS X Server (and maybe client)
  # 02/18/00 (belmonte)- Support for Cygwin.
+ # 12/08/03 (seiwald) - New YaccHdr to attribute #includes to generated .c.