evanlabs / gyp

Automatically exported from code.google.com/p/gyp
0 stars 0 forks source link

Dependencies are not set correctly when one static library depends on another one, and the first one #includes a file generated from an action in the second one (mac). #259

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Create a file: foo.m, which #imports generated.h
2. Put foo.m in a static library "target1" in gyp1.gyp
3. Create a file: bar.m, and put it in a static library "target2" in gyp2.gyp
4. Add an action to the "target2" to generate generated.h
5. Add a dependency on "target2" from "target1"
6. Build "target1" and notice that there is a compiler error due to generated.h 
not existing.

What is the expected output? What do you see instead?

The generated project file for gyp1 has no references to gyp2, and building 
target1 fails since generated.h is not found.

The generated project file should have added a target dependency on the 
"target2 Support" target, or on "target2" directly.

What version of the product are you using? On what operating system?
mac, r1167

Please provide any additional information below.
The scenario works fine if the action to generated the file is put in a 
separate target of type "none" within gyp2, and then have target1 depend on 
that.

Original issue reported on code.google.com by agri...@google.com on 17 Apr 2012 at 11:52

GoogleCodeExporter commented 9 years ago
It sounds like you failed to declare that 'target2' was a hard_dependency, and 
thus it was pruned from 'target1's dependency list, since they're both 
static_library target types.

http://code.google.com/p/gyp/wiki/InputFormatReference#Linking_Dependencies 
mentions this

If a target of type != 'none' is going to generate files that will be used by 
other targets (eg: headers being included), then you should ensure that such a 
target is marked hard_dependency. This will prevent it from being pruned. 
Further, if those generated header files are imported as part of a targets 
public headers (eg: target1 had a 'foo.h' that #imports generated.h), then 
target1 should make sure to export_dependent_settings: ['target2'], so that its 
dependents know about target2.

This will ensure that target1 (and, if exported, its dependents) do not attempt 
to compile until target2 has compiled & ran its actions (including generating 
headers)

Original comment by rsleevi@chromium.org on 28 Jun 2012 at 8:40

GoogleCodeExporter commented 9 years ago
Aha, that's exactly it. Thanks for this.
Not sure how to close the bug, but working as intended :)

Original comment by agri...@google.com on 29 Jun 2012 at 1:09