-
Notifications
You must be signed in to change notification settings - Fork 4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WIP: objc include_prefix/strip_include_prefix #5954
Conversation
(1) is simply because (2), I don't know off the bat, but I if you say it's because of ARCness, I believe you :) (3), I also don't know -- |
/cc @mhlopko |
(1) I see. And do you know where those implicit dependencies come from? There are a whole bunch in there that don't really seem like they should be there. I'd be interested in another PR to remove some of them and make the list closer to (2) What I found was that we are creating (3) I found that even though the two |
I mean that Doing some archeology, I found this commit, which seems to be the one that introduced creating a new I've played with some variations of this but I'm not sure how to fix it... if I just pass the
Then the action that creates the virtual directory doesn't run, even though the If I use the merged
Then my test works (
If anyone has any ideas what the right answer here is, I'm all ears... |
So I fixe one of the failures by adding a flag to the
However, if I copy and paste the command that failed:
it works. Could this be a race? |
|
It'd be worth also to double check what the rationale behind this other test is:
Aren't the headers of the |
@sergiocampama might know more details? |
I'm very confused about what the right behavior is. I did a bit of digging and in comments on #1802 there are mentions that propagating the This is blocking both this PR and #6243. |
This is no longer being pursued in this form. I'll take another crack once the C++ rules are in skylark. |
As per this design document, I am adding
include_prefix
andstrip_include_prefix
attributes to theobjc_library
rule.However, I'm noticing a few interesting things regarding the
objc_library
behavior when compared to thecc_library
behavior.I pulled the test cases from the integration tests, namely these files, and when I run them, I see the following output:
for
bazel_objc_test.sh
And for
bazel_cc_test.sh
:This makes me wonder a few things:
Why is the
objc_library
case loading so many more rules than thecc_library
rule? Some of them seem unnecessary, like for example all the python, bash, java, etc launchers.Why is the
objc_library
rule creating two separateCcCompilationContext
for each rule? If you look at theBUILD
files, the configuration is identical. It should be oneCcCompilationContext
per rule no?Why are the includes (in
CommandLineCcCompilationContext.includeDirs
) not being propagated? I have been looking for some difference between the two, but I still haven't figured it out.