Getting an iOS project's .xcodeproj working

[david.s...@gmail.com]

I've run into some behavior that I find surprising, but I'm not sure if it's something that's actually expected behavior, and I just don't understand bazel well enough to know what I'm doing wrong.

I was trying to get a simple iOS project going, and while I could get it to build the .ipa files successfully through bazel, I never managed to get a working .xcodeproj built by Bazel (by "working" I mean capable of performing the build within Xcode). However, the example objc project that comes with Bazel would create .xcodeproj files that could successfully build the project from within Xcode (at least, once I started passing --ios_sdk_version=8.2).

I tried to make my project as identical as possible to the example project, and never managed to get a .xcodeproj file that builds correctly in Xcode. The error would always take the form of an Xcode build phase's command complaining that it can't find some file, where the file path was always nearly correct, except instead of the path component for "MyProjectName", that component would be replaced with "bazel", which would work out in my directory organization to the directory where I build bazel from.

Once I realized that the examples/ directory was a symlink back to the bazel build dir, I tried copying the examples/ directory so that it was an actual directory in the same location instead of the symlink (with "cp -R examples examples2"). For example, here is the build error in Xcode on trying to build the examples/objc project from a directory that wasn't a symlink (examples2):

----
CpResource /Users/David/Documents/Development/bazel/examples2/objc/PrenotCalculator/Resources/test.txt /Users/David/Library/Developer/Xcode/DerivedData/PrenotCalculator-dczcvhtihmohrjfilhnjlgutlljs/Build/Products/Debug-iphonesimulator/PrenotCalculatorResources.bundle/test.txt
cd /var/tmp/_bazel_David/76c7c86320280f6baef6bf5759dc20fb/ProjectTest/bazel-out/local_darwin-fastbuild/bin/examples2/objc
export PATH="/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin:/Applications/Xcode.app/Contents/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin"
builtin-copy -exclude .DS_Store -exclude CVS -exclude .svn -exclude .git -exclude .hg -strip-debug-symbols -strip-tool /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strip -resolve-src-symlinks /Users/David/Documents/Development/bazel/examples2/objc/PrenotCalculator/Resources/test.txt /Users/David/Library/Developer/Xcode/DerivedData/PrenotCalculator-dczcvhtihmohrjfilhnjlgutlljs/Build/Products/Debug-iphonesimulator/PrenotCalculatorResources.bundle

error: /Users/David/Documents/Development/bazel/examples2/objc/PrenotCalculator/Resources/test.txt: No such file or directory
----

This file would exist, if the "bazel" in the path was replaced with "ProjectTest". So as far as I can tell, bazel is only creating .xcodeproj files capable of performing a build if they are being made from within a directory that is actually in the bazel build directory. Or at least, if the directory would be within the bazel build directory if the project's directory name was replaced with "bazel" in the full path.

Thanks,
David

[Han-Wen Nienhuys]

Do you have a workspace name defined in WORKSPACE ? What happens if
you rename the directory you are building bazel in to something else?
Does the erroneous path component change along?

> --
> You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.
> To post to this group, send email to bazel-...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/0b12af2f-fed4-4755-8b6a-b6d0d570eaad%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Han-Wen Nienhuys
Google Munich
han...@google.com

[david.s...@gmail.com]

On Tuesday, April 7, 2015 at 6:13:53 AM UTC-7, Han-Wen Nienhuys wrote:
> Do you have a workspace name defined in WORKSPACE ? What happens if
> you rename the directory you are building bazel in to something else?
> Does the erroneous path component change along?
>

I do not have a workspace name defined in WORKSPACE, it's just a blank WORKSPACE file (this is all done in a copy of bazel's base_workspace directory).

I renamed the bazel build directory to bazel2, updated the tools and third_party symlinks, as well as the arguments to build in .bazelrc to point to the new location. Once again, bazel build succeeds and generates the files, but when I open the project in Xcode, Xcode will give the same errors, except it now complains that it can't find things with the path component changed along to the new bazel2 directory.

I don't have any knowledge of how xcode projects should work, but I popped open the generated project.pbxproj and searched through it as text. The full path to the bazel director appears 6 times in the XML of this file, always in a complex of XML that suggests it is the value for a key. Examples:

----
<dict>
<key>isa</key>
<string>PBXGroup</string>
<key>name</key>
<string>mainGroup</string>
<key>path</key>
<string>/Users/David/Documents/Development/bazel2</string>
<key>sourceTree</key>
<string><![CDATA[<group>]]></string>
<key>children</key>
<array>
<string>B401C979DCDB0B5300000000</string>
<string>B401C9799EF61BFC00000000</string>
<string>B401C9792FADE24C00000000</string>
</array>
</dict>
----

and

----
<dict>
<key>isa</key>
<string>XCBuildConfiguration</string>
<key>name</key>
<string>Debug</string>
<key>buildSettings</key>
<dict>
<key>USER_HEADER_SEARCH_PATHS</key>
<array>
<string>$(WORKSPACE_ROOT)</string>
<string>$(WORKSPACE_ROOT)/bazel-out/local_darwin-fastbuild/genfiles</string>
<string>$(WORKSPACE_ROOT)</string>
</array>
<key>HEADER_SEARCH_PATHS</key>
<array>
<string>$(inherited)</string>
</array>
<key>FRAMEWORK_SEARCH_PATHS</key>
<array>
<string>$(SDKROOT)/Developer/Library/Frameworks</string>
<string>$(PLATFORM_DIR)/Developer/Library/Frameworks</string>
</array>
<key>WORKSPACE_ROOT</key>
<string>/Users/David/Documents/Development/bazel2</string>
...
(plenty more)
...
----

The path to my project workspace and source code does not appear in the pbxproj.

I tried to do a little searching through the bazel source code. I'm way too new to this code to really know what is going on, but I did notice the function com.google.devtools.build.xcode.xcodegen.XcodeprojGeneration.xcodeproj() takes an argument called workspaceRoot. This function appears, according to grep, to only be called from com.google.devtools.build.xcode.xcodegen.XcodeGen.main(). In the function, workspaceRoot is created with this code:

----
Path workspaceRoot;
if (!Files.exists(symlinkToInsideWorkspace)) {
workspaceRoot = XcodeprojGeneration.relativeWorkspaceRoot(pbxprojPath);
} else {
// Get the absolute path to the workspace root.

// TODO(bazel-team): Remove this hack, possibly by converting Xcodegen to be run with
// "bazel run" and using RUNFILES to get the workspace root. For now, this is needed to work
// around Xcode's handling of symlinks not playing nicely with how Bazel stores output
// artifacts in /private/var/tmp. This means a relative path from .xcodeproj in bazel-out to
// the workspace root in .xcodeproj will not work properly at certain times during
// Xcode/xcodebuild execution.
workspaceRoot = symlinkToInsideWorkspace
.toRealPath()
.resolve("../../..")
.normalize();
}
----

I could be totally off in the weeds, but it seems relevant. I don't know what to change there to see if there's any improvement, though.

David

[Han-Wen Nienhuys]

I think Peter is the expert on this code.

> --
> You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.
> To post to this group, send email to bazel-...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/fd2cb54e-03c4-4077-b0c5-631e1f0031db%40googlegroups.com.

[Daniel Wagner-Hall]

Could you cd to the directory containing the generated xcodeproj, and dump the full output of this somewhere?

/usr/bin/xcodebuild ARCHS=i386 SYMROOT=/tmp/symroot OBJROOT=/tmp/objroot -project PrenotCalculator.xcodeproj -target PrenotCalculator_objc_examples -sdk iphonesimulator8.2

This worked for me (except with 8.1, because that's the xcode I have installed)

My full sequence of commands was:

[cd to fresh bazel clone]

./compile.sh

cd examples

../output/bazel build objc:PrenotCalculator

cd ../bazel-bin/examples/objc

/usr/bin/xcodebuild ARCHS=i386 SYMROOT=/tmp/symroot OBJROOT=/tmp/objroot -project PrenotCalculator.xcodeproj -target PrenotCalculator_objc_examples -sdk iphonesimulator8.1

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/CAFQ2z_OK4rho7K_4tx2%3DHpygMj3rjgCtEmKM0mfis3x7gt9rpw%40mail.gmail.com.

[david.s...@gmail.com]

On Tuesday, April 7, 2015 at 11:46:46 PM UTC-7, dawagner wrote:
> Could you cd to the directory containing the generated xcodeproj, and dump the full output of this somewhere?
>
>
> /usr/bin/xcodebuild ARCHS=i386 SYMROOT=/tmp/symroot OBJROOT=/tmp/objroot -project PrenotCalculator.xcodeproj -target PrenotCalculator_objc_examples -sdk iphonesimulator8.2
>
>
> This worked for me (except with 8.1, because that's the xcode I have installed)
>
>
> My full sequence of commands was:
>
>
> [cd to fresh bazel clone]
> ./compile.sh
>
> cd examples
> ../output/bazel build objc:PrenotCalculator
>
> cd ../bazel-bin/examples/objc
>
> /usr/bin/xcodebuild ARCHS=i386 SYMROOT=/tmp/symroot OBJROOT=/tmp/objroot -project PrenotCalculator.xcodeproj -target PrenotCalculator_objc_examples -sdk iphonesimulator8.1

Sure. I'll do your commands and post the output, though I will point out that I also got this same sequence to work in Xcode. The situation that doesn't work is building Xcode projects that aren't in bazel's own workspace.

I also went through and did something pretty close to your commands for a directory which isn't in bazel's workspace, and posted that output as well.

The two output logs are here: https://gist.github.com/davidsantiago/6c62f76c30b7b47f4770

It looks to me like the problem does originate in /src/objc_tools/xcodegen/java/com/google/devtools/build/xcode/xcodegen/XcodeGen.java, which I posted a snippet from earlier. It attempts to find the workspace root by taking a jar it knows must be there, and resolving three directories above it. But since the jar is there through a symlink, it resolves to the canonical path in the bazel dir. This happens whether the tools symlink is in your workspace or the new functionality that sets the tools directory in the .bazelrc is being used. It seems like the location of this jar determining the workspace root was a valid assumption to make at some point, but not anymore.

If there was an alternate way to get the workspace root to xcodegen, then it could generate the absolute paths it needs to avoid the relative symlinks that give Xcode trouble. The comment in the snippet I quoted earlier suggests doing this with bazel run and runfiles. I'm not sure how to do that myself. My thought would be to try to hack in another command line option for xcodegen to receive the workspace root from the build tasks that invoke it, since it is already receiving the "--control" command line argument. That seems easier than the runfiles approach, so I'm sure that the TODO has its reasons for not adding args, though they aren't apparent to me.

[Han-Wen Nienhuys]

On Wed, Apr 8, 2015 at 12:18 PM, <david.s...@gmail.com> wrote:
> On Tuesday, April 7, 2015 at 11:46:46 PM UTC-7, dawagner wrote:
>> Could you cd to the directory containing the generated xcodeproj, and dump the full output of this somewhere?
>>
>> /usr/bin/xcodebuild ARCHS=i386 SYMROOT=/tmp/symroot OBJROOT=/tmp/objroot -project PrenotCalculator.xcodeproj -target PrenotCalculator_objc_examples -sdk iphonesimulator8.2
>>
>>
>> This worked for me (except with 8.1, because that's the xcode I have installed)
>>
>>
>> My full sequence of commands was:
>>
>>
>> [cd to fresh bazel clone]
>> ./compile.sh
>>
>> cd examples
>> ../output/bazel build objc:PrenotCalculator
>>
>> cd ../bazel-bin/examples/objc
>>
>> /usr/bin/xcodebuild ARCHS=i386 SYMROOT=/tmp/symroot OBJROOT=/tmp/objroot -project PrenotCalculator.xcodeproj -target PrenotCalculator_objc_examples -sdk iphonesimulator8.1
>
> Sure. I'll do your commands and post the output, though I will point out that I also got this same sequence to work in Xcode. The situation that doesn't work is building Xcode projects that aren't in bazel's own workspace.
>
> I also went through and did something pretty close to your commands for a directory which isn't in bazel's workspace, and posted that output as well.
>
> The two output logs are here: https://gist.github.com/davidsantiago/6c62f76c30b7b47f4770
>
> It looks to me like the problem does originate in /src/objc_tools/xcodegen/java/com/google/devtools/build/xcode/xcodegen/XcodeGen.java, which I posted a snippet from earlier. It attempts to find the workspace root by taking a jar it knows must be there, and resolving three directories above it.

Ah, now I understand the problem.

Daniel,

couldn't xcodegen be given the exec-path to a source file of the
project? We could count the number of path components, and then deref
the path and go up that number of parent directories.

> If there was an alternate way to get the workspace root to xcodegen, then it could generate the absolute paths it needs to avoid the relative symlinks that give Xcode trouble. The comment in the snippet I quoted earlier suggests doing this with bazel run and runfiles. I'm not sure how to do that myself. My thought would be to try to hack in another command line option for xcodegen to receive the workspace root from the build tasks that invoke it, since it is already receiving the "--control" command line argument. That seems easier than the runfiles approach, so I'm sure that the TODO has its reasons for not adding args, though they aren't apparent to me.

the workspace root would typically be an absolute path, which we don't
want to have inside command lines, because the client machine state
(where the workspace lives) would leak into something we want to cache
remotely.

[david.s...@gmail.com]

> the workspace root would typically be an absolute path, which we don't
> want to have inside command lines, because the client machine state
> (where the workspace lives) would leak into something we want to cache
> remotely.

Ah, of course. Knew there had to be a reason.

[Daniel Wagner-Hall]

On 8 April 2015 at 06:24, 'Han-Wen Nienhuys' via bazel-discuss <bazel-...@googlegroups.com> wrote:

On Wed, Apr 8, 2015 at 12:18 PM,  <david.s...@gmail.com> wrote:
> On Tuesday, April 7, 2015 at 11:46:46 PM UTC-7, dawagner wrote:
>> Could you cd to the directory containing the generated xcodeproj, and dump the full output of this somewhere?
>>
>> /usr/bin/xcodebuild ARCHS=i386 SYMROOT=/tmp/symroot OBJROOT=/tmp/objroot -project PrenotCalculator.xcodeproj -target PrenotCalculator_objc_examples -sdk iphonesimulator8.2
>>
>>
>> This worked for me (except with 8.1, because that's the xcode I have installed)
>>
>>
>> My full sequence of commands was:
>>
>>
>> [cd to fresh bazel clone]
>> ./compile.sh
>>
>> cd examples
>> ../output/bazel build objc:PrenotCalculator
>>
>> cd ../bazel-bin/examples/objc
>>
>> /usr/bin/xcodebuild ARCHS=i386 SYMROOT=/tmp/symroot OBJROOT=/tmp/objroot -project PrenotCalculator.xcodeproj -target PrenotCalculator_objc_examples -sdk iphonesimulator8.1
>
> Sure. I'll do your commands and post the output, though I will point out that I also got this same sequence to work in Xcode. The situation that doesn't work is building Xcode projects that aren't in bazel's own workspace.
>
> I also went through and did something pretty close to your commands for a directory which isn't in bazel's workspace, and posted that output as well.
>
> The two output logs are here: https://gist.github.com/davidsantiago/6c62f76c30b7b47f4770
>
> It looks to me like the problem does originate in /src/objc_tools/xcodegen/java/com/google/devtools/build/xcode/xcodegen/XcodeGen.java, which I posted a snippet from earlier. It attempts to find the workspace root by taking a jar it knows must be there, and resolving three directories above it.

Ah, now I understand the problem.

Daniel,

couldn't xcodegen be given the exec-path to a source file of the
project? We could count the number of path components, and then deref
the path and go up that number of parent directories.

I *believe* that's exactly what happens, with the WORKSPACE_ROOT variable.

David: If you throw in a custom setting of WORKSPACE_ROOT when running from the command line, does it work? i.e. run:

/usr/bin/xcodebuild ARCHS=i386 SYMROOT=/tmp/symroot OBJROOT=/tmp/objroot WORKSPACE_ROOT=$(pwd) -project PrenotCalculator.xcodeproj -target PrenotCalculator_objc_examples -sdk iphonesimulator8.2

> If there was an alternate way to get the workspace root to xcodegen, then it could generate the absolute paths it needs to avoid the relative symlinks that give Xcode trouble. The comment in the snippet I quoted earlier suggests doing this with bazel run and runfiles. I'm not sure how to do that myself. My thought would be to try to hack in another command line option for xcodegen to receive the workspace root from the build tasks that invoke it, since it is already receiving the "--control" command line argument. That seems easier than the runfiles approach, so I'm sure that the TODO has its reasons for not adding args, though they aren't apparent to me.

the workspace root would typically be an absolute path, which we don't
want to have inside command lines, because the client machine state
(where the workspace lives) would leak into something we want to cache
remotely.

--
Han-Wen Nienhuys
Google Munich
han...@google.com

--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.
To post to this group, send email to bazel-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/CAFQ2z_NuyEZWP0GgGrb67a%3Da%2B8b4x1PnObsMdjEOqLP6yUsYNw%40mail.gmail.com.

[david.s...@gmail.com]

> couldn't xcodegen be given the exec-path to a source file of the
>
> project? We could count the number of path components, and then deref
>
> the path and go up that number of parent directories.
>
>
>
> I *believe* that's exactly what happens, with the WORKSPACE_ROOT variable.
>
>
>
>
> David: If you throw in a custom setting of WORKSPACE_ROOT when running from the command line, does it work? i.e. run:
>
>
> /usr/bin/xcodebuild ARCHS=i386 SYMROOT=/tmp/symroot OBJROOT=/tmp/objroot WORKSPACE_ROOT=$(pwd) -project PrenotCalculator.xcodeproj -target PrenotCalculator_objc_examples -sdk iphonesimulator8.2

Daniel: Just tried this. It still fails in the same way (finds itself in the bazel workspace, where the file doesn't exist). Here's the full output of my terminal session: https://gist.github.com/davidsantiago/1cc135c3001ff043b48c I changed the directory path to examples2, so that when it messes up and goes into bazel's workspace, it doesn't happen to find bazel/examples, build the same directory from there, and look like it worked.

[Daniel Wagner-Hall]

Ok, I get what's going on here.

The root cause here is that bazel outputs the xcodeproj in one place (bazel-out/local_darwin-fastbuild/bin) and creates a symlink pointing to it in another (bazel-bin).

Xcode needs to know where to find source files and such, and either needs to know 1) they're relative to the xcodeproj, or 2) absolute paths to them.

We can't use relative paths, because we have two locations from which the xcodeproj may be referenced (bazel-bin or bazel-out/...) - even less conveniently, people tend to open the bazel-bin one (because it's what's printed by bazel), but the one we actually write (so where we actually know paths) is bazel-out/...

So we need to use absolute paths. Unfortunately, this means we need to save an absolute path in the project file *somewhere*. Right now, we save it in a few places:

1) The path of the mainGroup root

2) The value of the WORKSPACE_ROOT variable in each configuration

Really, we should only save it in one place. I've just sent a change to fix this internally in Google (unfortunately, this section of code isn't publicly contributable-to yet).

After my change, you can override the WORKSPACE_ROOT variable (either on the command line, or in the Xcode UI) and things should start working.

Unfortunately, we still need to specify the absolute path of the WORKSPACE_ROOT *somewhere*, unless anyone has any smarter ideas :)

 

--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discus...@googlegroups.com.
To post to this group, send email to bazel-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/58417064-0fcb-402d-8161-fdf24894c2d0%40googlegroups.com.

[david.s...@gmail.com]

> Ok, I get what's going on here.
>
>
> The root cause here is that bazel outputs the xcodeproj in one place (bazel-out/local_darwin-fastbuild/bin) and creates a symlink pointing to it in another (bazel-bin).
>
>
> Xcode needs to know where to find source files and such, and either needs to know 1) they're relative to the xcodeproj, or 2) absolute paths to them.
>
>
> We can't use relative paths, because we have two locations from which the xcodeproj may be referenced (bazel-bin or bazel-out/...) - even less conveniently, people tend to open the bazel-bin one (because it's what's printed by bazel), but the one we actually write (so where we actually know paths) is bazel-out/...
>
>
> So we need to use absolute paths. Unfortunately, this means we need to save an absolute path in the project file *somewhere*. Right now, we save it in a few places:
>
>
> 1) The path of the mainGroup root
> 2) The value of the WORKSPACE_ROOT variable in each configuration
>
>
> Really, we should only save it in one place. I've just sent a change to fix this internally in Google (unfortunately, this section of code isn't publicly contributable-to yet).
>
>
> After my change, you can override the WORKSPACE_ROOT variable (either on the command line, or in the Xcode UI) and things should start working.
>
>
> Unfortunately, we still need to specify the absolute path of the WORKSPACE_ROOT *somewhere*, unless anyone has any smarter ideas :)

OK, great. Though, I'm a little unclear when you say that the fix was to something that isn't publicly contributable-to... does that mean the fix won't appear in the open source bazel release any time soon?

In the meantime, I had actually gone ahead and implemented Han-Wen's suggestion as a proof-of-concept for an alternate way to determine the workspace root. His suggestion works and I was able to generate .xcodeproj files that would successfully build the example project from within Xcode, because they determine the workspace root from the source file paths in the Control object passed to xcodegen. It sounds from your email like this might now be moot, but I thought I'd report that it works, at least. It is certainly letting me push forward until the fix appears in public.

[Han-Wen Nienhuys]

On Thu, Apr 9, 2015 at 12:08 PM, <david.s...@gmail.com> wrote:
>> Ok, I get what's going on here.
>>
>>
>> The root cause here is that bazel outputs the xcodeproj in one place (bazel-out/local_darwin-fastbuild/bin) and creates a symlink pointing to it in another (bazel-bin).
>>
>>
>> Xcode needs to know where to find source files and such, and either needs to know 1) they're relative to the xcodeproj, or 2) absolute paths to them.
>>
>>
>> We can't use relative paths, because we have two locations from which the xcodeproj may be referenced (bazel-bin or bazel-out/...) - even less conveniently, people tend to open the bazel-bin one (because it's what's printed by bazel), but the one we actually write (so where we actually know paths) is bazel-out/...
>>
>>
>> So we need to use absolute paths. Unfortunately, this means we need to save an absolute path in the project file *somewhere*. Right now, we save it in a few places:
>>
>>
>> 1) The path of the mainGroup root
>> 2) The value of the WORKSPACE_ROOT variable in each configuration
>>
>>
>> Really, we should only save it in one place. I've just sent a change to fix this internally in Google (unfortunately, this section of code isn't publicly contributable-to yet).
>>
>>
>> After my change, you can override the WORKSPACE_ROOT variable (either on the command line, or in the Xcode UI) and things should start working.
>>
>>
>> Unfortunately, we still need to specify the absolute path of the WORKSPACE_ROOT *somewhere*, unless anyone has any smarter ideas :)
>
> OK, great. Though, I'm a little unclear when you say that the fix was to something that isn't publicly contributable-to... does that mean the fix won't appear in the open source bazel release any time soon?

We have a separate area in the version control system for files with
external contributions, so in order to accept contributions from
non-Googlers, we have to shuffle around files internally. Damien (CC)
has been doing a lot of work behind the scenes, and can give you an
ETA for when your change could be accepted. (which file did you
change?)

> In the meantime, I had actually gone ahead and implemented Han-Wen's suggestion as a proof-of-concept for an alternate way to determine the workspace root. His suggestion works and I was able to generate .xcodeproj files that would successfully build the example project from within Xcode, because they determine the workspace root from the source file paths in the Control object passed to xcodegen. It sounds from your email like this might now be moot, but I thought I'd report that it works, at least. It is certainly letting me push forward until the fix appears in public.

[Damien Martin-guillerez]

I don't know which code needs to be changed if it's the tooling then as soon as Peter and Daniel review it, for the rules it should be possible now. for the rest of the java code I would say early next week

[david.s...@gmail.com]

> We have a separate area in the version control system for files with
> external contributions, so in order to accept contributions from
> non-Googlers, we have to shuffle around files internally. Damien (CC)
> has been doing a lot of work behind the scenes, and can give you an
> ETA for when your change could be accepted. (which file did you
> change?)

Oh, OK. I only had to change about twenty lines in src/objc_tools/xcodegen/java/com/google/devtools/build/xcode/xcodegen/XcodeGen.java. Happy to work with you guys to pass that stuff on through the contribution process when it's ready on your end.

[Damien Martin-guillerez]

CC: +Daniel Wagner-Hall

objc_tools is part of the code Peter and Daniel has to review so you can start preparing a gerrit review and we should be able to accept it pretty soon.

[david.s...@gmail.com]

On Thursday, April 9, 2015 at 11:05:57 AM UTC-7, Damien Martin-guillerez wrote:
> CC: +Daniel Wagner-Hall
>
> objc_tools is part of the code Peter and Daniel has to review so you can start preparing a gerrit review and we should be able to accept it pretty soon.

I've tried getting set up in gerrit, but I'm having some difficulty. I've tried following the documentation here: https://gerrit-review.googlesource.com/Documentation/user-upload.html But I don't seem to have any way to set a username for SSH, or set SSH keys in the Settings panel, the options the documentation refers to simply aren't there for me. Not sure how to proceed.

Thanks,
David

[Damien Martin-guillerez]

Hello, once you logged into bazel-review.googlesource.com go to your user name -> Settings then go to "HTTP Password" -> "Obtain password" you will be given instruction to configure your git cookies.

Then pushing should be "git push https://bazel-review.googlesource.com refs/for/master"

(https://gerrit-review.googlesource.com/Documentation/user-upload.html#http)

--
You received this message because you are subscribed to the Google Groups "bazel-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to bazel-discuss+unsubscribe@googlegroups.com.

To post to this group, send email to bazel-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/bazel-discuss/87011831-358d-4c7d-8e20-54d7c61380b0%40googlegroups.com.

[david.s...@gmail.com]

On Friday, April 10, 2015 at 3:37:13 AM UTC-7, Damien Martin-guillerez wrote:
> Hello, once you logged into bazel-review.googlesource.com go to your user name -> Settings then go to "HTTP Password" -> "Obtain password" you will be given instruction to configure your git cookies.
>
>
> Then pushing should be "git push https://bazel-review.googlesource.com refs/for/master"
>
>
> (https://gerrit-review.googlesource.com/Documentation/user-upload.html#http)

OK, thanks again. That page you linked doesn't actually explain that git pushing to the https:// URL is an option, and this is my first time using gerrit. I wasn't able to make that exact command work, though I did succeed with "git push https://bazel.googlesource.com/bazel HEAD:refs/for/master".