[haiku-commits] Re: buildbot failure in HAIKU on (whole buildset)
- From: "Adrien Destugues" <pulkomandy@xxxxxxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Mon, 15 Jun 2015 13:45:26 +0000
After ruling out that the feature is actually needed, the placement of the
yacc/lex generated
sources could be changed to the architecture common directory. However, the
Yacc/Lex invocations
must consequently be moved out of the MultiArchSubDirSetup loops, so that the
rule isn't invoked
multiple times for the same output file. Since that makes things more
complicated, I'd rather avoid
this solution, if possible.
ok.
On 06/14/2015 08:18 PM, Adrien Destugues wrote:
It seems we hit a dependency problem between a lex generated file and
a yacc generated one, however I can't reproduce the issue locally
(tried on 2 different machines). Help fixing this is welcome.
I have noticed this:
Includes "<src!kits!network!netresolv!x86_gcc2>nslexer.l" :
"<src!kits!network!netresolv>nsparser.h" ;
Depends "<src!kits!network!netresolv!x86_gcc2>nsparser.h" :
"<src!kits!network!netresolv!x86_gcc2>nsparser.y" ;
The grist for nsparser.h in the first line looks wrong (it's missing
the x86_gcc2). However I'm not sure why and how to fix that.
The name of the header file target that is passed to the Yacc rule is derived
from the name of the
object target (cf. Object rule) which in turn is derived from the name of the
yacc source file
target (cf. Objects rule), so they all have the same grist. The Includes
dependency the Yacc rule
generates should therefore have the correct grist.
The incorrect Includes dependency probably stems from jam's automatic header
scanning. It uses the
value of the HDRGRIST variable. Setting it accordingly in
MultiArchSubDirSetup should fix that
issue. However, since the correct dependency should be declared anyway (by
the Yacc rule) and
missing includes are simple ignored during jam's make phase, that shouldn't
really result in a
different outcome. However, since there are known issues with jam's handling
of Includes
dependencies, maybe it does nevertheless.
In this case, the failing dependency is from the Lex file (nslexer.l) to a
header generated by Yacc (nsparser.h). So we can only rely on the header
scanning to handle this (the Yacc rule only declare a dependency between the c
and h file it generates, not anything else using the .h).
I'll see if I can get things working with HDRGRIST, thanks.
--
Adrien.
Other related posts:
