According to customer feedback:
Packaging happens every time a build is triggered.

In development phase, this is not needed. We should not wait for the packaging to be over to launch the simulator.

Should packaging be be an explicit output?

Tulsi IDE has a configuration to add environment variables but it seems to be a single line configuration. Adding a \n doesn't work as it is encoded with an extra \. One workaround to add multiple environment variables is to manually edit Configs/<project-name>.tulsigen and/or project.tulsiconf and add a \n to separate multiple environment variables. Am I missing something or is there a better way to do this?

\cc @DavidGoldman @reinhillmann @dierksen

Crossposting from bazelbuild/rules_apple#124

Tried building the example project from https://github.com/bazelbuild/rules_apple which can build from command line but fails from the tulsi generated xcode project

After generating the project at //examples/ios/HelloWorldSwift and then building to simulator from Xcode I get the following error:

Queuing Tulsi build...
<*> Acquiring /tmp/tulsi_bazel_build.lock completed in 0.045 ms
<*> Parsing options completed in 0.226 ms
Running "/Users/kieranlafferty/Desktop/0.8.1/bin/bazel build --verbose_failures --announce_rc --config=ios_x86_64 --copt=-fdebug-prefix-map=/private/var/tmp/_bazel_kieranlafferty/1dc090ed74e4e94615251a88a9076015/execroot=/Users/kieranlafferty/Downloads --compilation_mode=dbg --xcode_version=9.2 --ios_sdk_version=11.2 --build_event_json_file=/Users/kieranlafferty/Desktop/0.8.1/bin/SwiftDemo.xcodeproj/.tulsi/24765_build_events.json --output_groups=tulsi-outputs,default --aspects @tulsi//tulsi:tulsi_aspects.bzl%tulsi_outputs_aspect --override_repository=tulsi=/Users/kieranlafferty/Desktop/0.8.1/bin/SwiftDemo.xcodeproj/.tulsi/Bazel --tool_tag=tulsi:bazel_build --apple_generate_dsym --define=bazel_rules_apple.propagate_embedded_extra_outputs=1 //examples/ios/HelloWorldSwift:HelloWorldSwift", patching output for main group path at "/Users/kieranlafferty/Downloads/rules_apple-master" with project path at "/Users/kieranlafferty/Desktop/0.8.1/bin".
WARNING: Config values are not defined in any .rc file: ios_x86_64
INFO: Options provided by the client:
  Inherited 'common' options: --isatty=0 --terminal_columns=80
Loading: 
Loading: 0 packages loaded
Analyzing: target //examples/ios/HelloWorldSwift:HelloWorldSwift (23 packages loaded)
INFO: Analysed target //examples/ios/HelloWorldSwift:HelloWorldSwift (26 packages loaded).
INFO: Found 1 target...
[10 / 21] BazelWorkspaceStatusAction stable-status.txt
ERROR: /Users/kieranlafferty/Downloads/rules_apple-master/examples/ios/HelloWorldSwift/BUILD:18:1: output 'examples/ios/HelloWorldSwift/HelloWorldSwift.apple_binary.app.dSYM.temp.zip' was not created
ERROR: /Users/kieranlafferty/Downloads/rules_apple-master/examples/ios/HelloWorldSwift/BUILD:18:1: not all outputs were created or valid
INFO: Elapsed time: 1.543s, Critical Path: 0.16s
FAILED: Build did NOT complete successfully
:: error: Bazel build failed.
<*> Running Bazel completed in 1751.733 ms
<*> Everything completed in 1752.354 ms

Bazel Version 0.8.1
Tulsi Version 0.4.178909500.20171213 (0.4.178909500.20171213)

Any idea why this is failing for me?

Also any slack group or other useful resources other than the main documentation?

See repro project

Here's a small example, with a dummy genrule that just copies a file to be used as a header:

BUILD:

genrule(
    name = "dep",
    srcs = ["dep.in"],
    outs = ["dep.h"],
    cmd = "cp $(location dep.in) $@",
)

cc_binary(
    name = "main",
    srcs = [
        "main.cc",
        ":dep",
    ],
)

dep.in

inline int foo() { return 42; }

main.cc

#include "test/dep.h"
#include <iostream>

int main() {
  std::cout << foo() << "\n";
  return 0;
}

When I run Tulsi with this BUILD file, I want the file dep.in included in my Xcode project. (Reason: it's the source file, so I want to be able to edit it in Xcode and then recompile.)

Instead, the most I can see (if I select absolutely everything when generating the project) is the generated test/dep.h.

The official Bazel installation instructions recommend using Homebrew: https://docs.bazel.build/versions/master/install-os-x.html

Using this version of bazel in Tulsi is unintuitive, since it's in /usr/local/bin and the standard Finder open dialog requires you to use Cmd+Shift+G to open that directory.

Recommendation: auto-detect bazel versions in PATH and use those by default?

See https://github.com/dflems/bazel-repro/tree/master/tulsi-local-repo for an example project.

When using BUILD.bazel files (i.e. package/BUILD.bazel), Tulsi adds both package/BUILD and package/BUILD.bazel as file references in the Xcodeproj even though only the BUILD.bazel file exists.

My environment:
bazel: 0.17.2
rules_apple: 0.7.0
tulsi: master (dcd32cf)

Generate fail when ios_unit_test or ios_ui_test involved (Fine with ios_application,objc_library....)

Message log:
ERROR: /opt/iOS/loktar/bili-universal/Test/BUILD:10:1: in @tulsi//tulsi:tulsi_aspects.bzl%tulsi_sources_aspect aspect on apple_ui_test rule //bili-universal/Test:main_test: Traceback (most recent call last):
File "/opt/iOS/loktar/bili-universal/Test/BUILD", line 10
@tulsi//tulsi:tulsi_aspects.bzl%tulsi_sources_aspect(...)
File "/private/tmp/loktar-bazel/external/tulsi/tulsi/tulsi_aspects.bzl", line 768, in _tulsi_sources_aspect
provider.deps
'AppleTestInfo' object has no attribute 'deps'
Available attributes: includes, module_maps, non_arc_sources, sources, swift_modules
ERROR: Analysis of aspect '@tulsi//tulsi:tulsi_aspects.bzl%tulsi_sources_aspect of //bili-universal/Test:main_test' failed; build aborted: Analysis of target '//bili-universal/Test:main_test' failed; build aborted
General failure: Bazel aspects could not be built.

Tulsi only transfer the includes header defines in include label into HEADER_SEARCH_PATHS
Mostly we should hide inner header for preventing other lib using it, so flags like -iquote or -I is necessary in some rule like objc_library.copts

So I create a patch for seperating the copts and move the search path part into HEADER_SEARCH_PATHS #56

Tulsi will complain if you have bazel- anywhere in the path. Should'nt be the check scoped to the directory where the WORKSPACE file resides?

In this screenshot, my project is in a directory called bazel-blog-post.

The current Xcode project contains absolute paths in it. This unfortunately, makes Tulsi Xcode project not reusable across build nodes: they can't be shared among developers or CI machines.

My workflow involves checking in the Xcode project due to generation speed ( side effect from the aspect API, which requires a build bazelbuild/bazel#3036 ). I'm effectively using git as a cache for these Xcode projects. To write Xcode projects that works seamlessly on any build node, I think eventually everything in the project should be a relative path.

I link a Bazel binary into the WORKSPACE - this makes it easy to manage Bazel versions across commits and have a sandboxed WORKSPACE. With this change in Tulsi, I can point tulsi at that relative path.

Also, Xcode projects conventionally contain only relative paths: an Xcode project doesn't have dependencies on user level or transient absolute paths.

I've already started to add this support, which gets an Xcode project that is somewhat shareable. The first commit towards a full relative Xcode project is a relative Bazel: pinterest#2 🚀

Weather out not I will need 100% relative projects depends on what performance looks like for generating an Xcode project for the entire WORKSPACE: I may need to iterate more on this soon.

Tulsi is calling 'bazel build ... --config=$platform_$arch ...', but there's no bazelrc file to specify this behavior. This results in errors like:
WARNING: Config values are not defined in any .rc file: ios_arm64
and device builds don't work out of the box.

The file src/Tulsi.xcodeproj doesn't seem to exist. Has the build changed?

Tulsi will generate a project with dummy groups which cause create file or directory(Add File to xxx & New Group) in xcode on the root path by default.

And I found that there was a refactor for group/filereference structure(68c0b20)
Why consider using dummy group instead of real one?

It doesn't find the tulsiinfo files. This is because the event logs look like

            {
                "name": "external/bazel_j2objc/jre_security_lib.tulsiinfo",
                "uri": "bytestream://null/blobs/d52a2a73180de9a81631b96cdf51613ad96a6464/292"
            },

with the bytestream uri, instead of a file:// URI

This is using master of bazel @ 210cdeb8a7836c5fd586a29d73c8013f325d3883

I think it will reproduce on any project if --experimental_local_disk_cache and --experimental_local_disk_cache_path are used.

Why are cc_test targets nor supported?

Bug is similar to #24, but with external genfiles.

Paths for genfiles from external projects are not being configured correctly as seen here:.

Can repro it with this project/sha and the tulsiproj included: mikelikespie/swiftled@c7a0a1e

This is with latest master of tulsi.

I'm hitting issues with debugging macos_unit_test projects where by source mapping is not working. It looks to be related to the lldbinit trickery happening in Tulsi's bazel_build.py.
This is with the latest master branch Tulsi, 0.1.0 rules_apple, bazel 0.7.0, and Xcode 8.3.3.

This is what's in my xcode error listing:

:: warning: Found target source path not on local filesystem: /private/var/tmp/_bazel_benvanik/f449376ffd0ffc022ef6da9df0dfa2e2/bazel-sandbox/6691004218007129208/execroot
:: warning: Ignoring path. Debugging might not work as expected.
:: warning: Found target source path not on local filesystem: /private/var/tmp/_bazel_benvanik/f449376ffd0ffc022ef6da9df0dfa2e2/bazel-sandbox/4174916834773917042/execroot
:: warning: Ignoring path. Debugging might not work as expected.
:: warning: Found target source path not on local filesystem: /private/var/tmp/_bazel_benvanik/f449376ffd0ffc022ef6da9df0dfa2e2/bazel-sandbox/6184539997890225296/execroot
:: warning: Ignoring path. Debugging might not work as expected.
:: warning: Found target source path not on local filesystem: /private/var/tmp/_bazel_benvanik/f449376ffd0ffc022ef6da9df0dfa2e2/bazel-sandbox/8235419369364308518/execroot
:: warning: Ignoring path. Debugging might not work as expected.
:: warning: Extracted 0 source paths from 'arena_test_macos_xctest.xctest'. File-based breakpoints may not work. Please report as a bug.

My .lldbinit-tulsiproj is empty after the build because of these errors, and because the -fdebug-compilation-dir code is conditional Xcode/lldb have no clue how to find the source.

If I go and remove the conditional check here:
https://github.com/bazelbuild/tulsi/blob/master/src/TulsiGenerator/Scripts/bazel_build.py#L176

Debugging works! Is there a reason to not always include these options? It seems like they would be harmless and avoid some of the other bugs related to lldbinit (like needing to restart xcode). The documentation also states that these flags are being passed, when they aren't anymore.

Currently there are 0 releases of Tulsi so we've been building directly off of the latest master.

• The difficulty with this is that we are unsure what version of Bazel is compatible with the latest Tulsi changes.
• It would be helpful to understand the future roadmap / plans for Tulsi so we can contribute patches and features that are inline with the overall direction of the project.
• It is unclear what version of rules_apple is compatible with the latest Tulsi changes and when it is okay to update either project.

@steren for coordination

I am trying to build a simple Xcode project using Tulsi, but the Tulsi build keeps failing in Xcode anytime I try to run the project. The error is "Bazel build failed". I followed all the instructions and purposely made the Xcode project very simple yet it still still fails. I attached a screen shot of my file structure, the WORKSPACE file, and the BUILD file. The Bazel executable I'm using is what I downloaded from https://bazel.build/versions/master/docs/install-compile-source.html.

Please let me know if I can provide any more info to see why it keep failing.

Thank you.

WORKSPACE.TXT
BUILD.TXT

When an option or two change in the Tulsi code generation configs, we end up with a huge git/file diff. Most of the diff is because of a change in the order of the options rather than restricting it to just the options that changed.

Eg.

diff --git a/xyz-ios.tulsiproj/Configs/xyz-ios.tulsigen b/xyz-ios.tulsiproj/Configs/xyz-ios.tulsigen
index dce04925d..643494902 100644
--- a/xyz-ios.tulsiproj/Configs/xyz-ios.tulsigen
+++ b/xyz-ios.tulsiproj/Configs/xyz-ios.tulsigen
@@ -1,42 +1,48 @@
 {
+  "buildTargets" : [
+    "//:Xyz",
+    "//:XyzUITests",
+    "//:XyzUnitTests"
+  ],
   "optionSet" : {
-    "EnvironmentVariables" : {
+    "BazelBuildOptionsDebug" : {
       "p" : "$(inherited)"
     },
-    "CommandlineArguments" : {
+    "TestActionPostActionScript" : {
       "p" : "$(inherited)"
     },
-    "BazelBuildOptionsDebug" : {
+    "BazelBuildOptionsRelease" : {
       "p" : "$(inherited)"
     },
-    "TestActionPostActionScript" : {
+    "LaunchActionPreActionScript" : {
       "p" : "$(inherited)"
     },
-    "BazelBuildStartupOptionsRelease" : {
+    "BazelBuildStartupOptionsDebug" : {
       "p" : "$(inherited)"
     },
-    "BazelBuildOptionsRelease" : {
+    "BazelBuildStartupOptionsRelease" : {
       "p" : "$(inherited)"
     },
-    "TestActionPreActionScript" : {
+    "BuildActionPostActionScript" : {
       "p" : "$(inherited)"
     },
-    "LaunchActionPreActionScript" : {
+    "EnvironmentVariables" : {
       "p" : "$(inherited)"
     },
-    "LaunchActionPostActionScript" : {
+    "BuildActionPreActionScript" : {
       "p" : "$(inherited)"
     },
-    "BuildActionPreActionScript" : {
+    "CommandlineArguments" : {
       "p" : "$(inherited)"
     },
-    "BazelBuildStartupOptionsDebug" : {
+    "LaunchActionPostActionScript" : {
       "p" : "$(inherited)"
     },
-    "BuildActionPostActionScript" : {
+    "TestActionPreActionScript" : {
       "p" : "$(inherited)"
     }
   },
+  "projectName" : "xyz-ios",
   "sourceFilters" : [
     "Xyz/...",
     "XyzAPI/...",
@@ -44,17 +50,14 @@
     "XyzMocks/...",
     "XyzSiri/...",
     "XyzUITests/...",
-    "XyzUnitTests/..."
-  ],
-  "buildTargets" : [
-    "//:Xyz",
-    "//:XyzUITests",
-    "//:XyzUnitTests"
+    "XyzUnitTests/...",
+    "Pods/...",
+    "ThirdParty/...",
+    "external/..."
   ],
   "additionalFilePaths" : [
     "BUILD.bazel",
     "XyzDataModel/BUILD.bazel",
     "XyzAPI/BUILD.bazel"
-  ],
-  "projectName" : "xyz-ios"
+  ]
 }

All that changed in above file is the list of buildTargets, but since the order of other options changed, it resulted in a huge diff.
Is this a known issue with how the .codegen files are generated? Probable root cause if the absense of a fixed sequencing of the components while generating the .codegen file(s).

\cc @DavidGoldman, @dierksen, @reinhillmann, @keith, @vahidk

Hello Tulsi team! I'm currently using TulsiGenerator.framework and bazel_build.py script in the context of an Xcode project generator for Bazel, XCHammer. Overall, the setup is working quite well, so thanks to you all 🎉 !

Issue context

I'm in the process of updating to Bazel 0.16.1 and the HEAD of Tulsi. After the update, I noticed the build log isn't updated until the build is complete. There is no way to see the progress of the build as it executes actions.

What I've tried so far

After some testing, I found that the BEP json file is not updated until the build completes. I was wondering if anyone had any tips on what to do. Is there a hidden bit I can flip to stream all progress?

It looks like setting --build_event_publish_all_actions=true will cause Bazel to update the BEP json file more frequently. Still, it isn't nearly alive as the standard output UI.

Hi, I have an ios_application rule from the rules_apple repo in my BUILD file. It uses the app_icons parameter to supply an .xcassets catalog with the app icons. We don't change these very frequently, but it'd be ideal if Tulsi could make the .xcassets catalog available in the project that's generated.

Hi all,

Apparently Tulsi doesn't pass --apple_generate_dsym anymore, which prevents .dSYM generation, which in turn prevents breakpoint support.
When manually adding --apple_generate_dsym to the build options, breakpoints work properly.

Is there a reason this was removed ?

Thanks!

I'm trying to generate a Tulsi project for a codebase of mixed objective-c and swift targets. I'm using the new rules from the rules_apple repo.

For a smaller target with less dependencies, the project generates fine. However, when I select a target with more dependencies, bazel seems to fail with an out of memory error when I'm at the step where am going to select which source files I'd like to include in the project:

$ /private/var/tmp/_bazel_robbertvanginkel/06193c58a6c4b4a5fa1cd4f2ecd8b993/execroot/bazel/bazel-out/local-fastbuild/bin/src/bazel build -c dbg --symlink_prefix tulsigen- --announce_rc --nocheck_visibility --show_result=0 --package_path=%workspace%:/Users/robbertvanginkel/Library/Developer/Xcode/DerivedData/Tulsi-euigzcmqdbsljjdltfifpksghqom/Build/Products/Debug/Tulsi.app/Contents/Frameworks/TulsiGenerator.framework/Resources --aspects /tulsi/tulsi_aspects.bzl%tulsi_sources_aspect --output_groups=tulsi-info,-_,-default --experimental_show_artifacts //path/to/App:App
..........
INFO: Options provided by the client:
  Inherited 'common' options: --isatty=1 --terminal_columns=209
INFO: Reading options for 'build' from /Users/robbertvanginkel/Uber/mobile/ios/tools/bazel.rc:
  'build' options: --ios_minimum_os=8.0
INFO: Elapsed time: 284.662s
java.lang.OutOfMemoryError: Java heap space
	at java.util.Arrays.copyOf(Arrays.java:3332)
	at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:137)
	at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:121)
	at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:421)
	at java.lang.StringBuilder.append(StringBuilder.java:136)
	at com.google.devtools.build.lib.rules.SkylarkRuleClassFunctions$9.printJson(SkylarkRuleClassFunctions.java:991)
	at com.google.devtools.build.lib.rules.SkylarkRuleClassFunctions$9.printJson(SkylarkRuleClassFunctions.java:977)
	at com.google.devtools.build.lib.rules.SkylarkRuleClassFunctions$9.printJson(SkylarkRuleClassFunctions.java:986)
	at com.google.devtools.build.lib.rules.SkylarkRuleClassFunctions$9.printJson(SkylarkRuleClassFunctions.java:977)
	at com.google.devtools.build.lib.rules.SkylarkRuleClassFunctions$9.invoke(SkylarkRuleClassFunctions.java:958)
	at sun.reflect.GeneratedMethodAccessor91.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at com.google.devtools.build.lib.syntax.BuiltinFunction.call(BuiltinFunction.java:155)
	at com.google.devtools.build.lib.syntax.BaseFunction.call(BaseFunction.java:428)
	at com.google.devtools.build.lib.syntax.FuncallExpression.invokeObjectMethod(FuncallExpression.java:619)
	at com.google.devtools.build.lib.syntax.FuncallExpression.invokeObjectMethod(FuncallExpression.java:716)
	at com.google.devtools.build.lib.syntax.FuncallExpression.doEval(FuncallExpression.java:702)
	at com.google.devtools.build.lib.syntax.Expression.eval(Expression.java:43)
	at com.google.devtools.build.lib.syntax.FuncallExpression.evalArguments(FuncallExpression.java:675)
	at com.google.devtools.build.lib.syntax.FuncallExpression.invokeObjectMethod(FuncallExpression.java:715)
	at com.google.devtools.build.lib.syntax.FuncallExpression.doEval(FuncallExpression.java:702)
	at com.google.devtools.build.lib.syntax.Expression.eval(Expression.java:43)
	at com.google.devtools.build.lib.syntax.ExpressionStatement.doExec(ExpressionStatement.java:40)
	at com.google.devtools.build.lib.syntax.Statement.exec(Statement.java:31)
	at com.google.devtools.build.lib.syntax.UserDefinedFunction.call(UserDefinedFunction.java:81)
	at com.google.devtools.build.lib.syntax.BaseFunction.call(BaseFunction.java:428)
	at com.google.devtools.build.lib.skyframe.SkylarkAspectFactory.create(SkylarkAspectFactory.java:75)
	at com.google.devtools.build.lib.analysis.ConfiguredTargetFactory.createAspect(ConfiguredTargetFactory.java:358)
	at com.google.devtools.build.lib.skyframe.AspectFunction.createAspect(AspectFunction.java:441)
	at com.google.devtools.build.lib.skyframe.AspectFunction.compute(AspectFunction.java:299)
	at com.google.devtools.build.skyframe.ParallelEvaluator$Evaluate.run(ParallelEvaluator.java:381)
Java heap space

bazel ran out of memory and crashed.

If I bazel build //path/to/App:App then bazel runs without memory issues and builds the app. I've also tried to increase the available jvm memory. Previously this seemed to fail when the java process was using ~4GB of memory. I tried doubling the available amount by adding --host_jvm_args=-Xmx8g to the command, but it still fails.

Breakpoints cannot be set in other Xcode projects after a Bazel build has been performed from a Tulsi project.

Tulsi invokes src/TulsiGenerator/Scripts/bazel_build.py as its build step when building the generated Xcode project. After the build is complete, the script creates (or amends) an .lldbinit file to set up a source map:

# This file is autogenerated by Tulsi and should not be edited.
# This maps file paths used by Bazel to those used by 'SpotifyTulsi.xcodeproj'.
settings set target.source-map "/private/var/tmp/_bazel_tmarsh/e04175512e2ea0cad2046ce58e484c7d/execroot" "/Users/tmarsh/git"

Method to repro:

• Generate an Xcode project with Tulsi
• Open resulting project, set breakpoint (e.g., on main) and verify that breakpoint is hit when the project is run
• Close Xcode completely, and then open any other Xcode project
• Perform the same experiment, setting a breakpoint (e.g., on main) and see that the breakpoint is not hit

I couldn't find any documentation on target.source-maps in lldb docs, but it appears that it should only be used during a given session and not used as a persistent global setting.

They are in discrete folders in a Tulsi-generated project, unlike Xcode which nests them like this:

We tried to use Tulsi to generate an Xcode project for a C++ library to be built with Bazel, and it failed, with the error message “Unsupported target: cc_binary”. I hope this will be supported in the future.

I posted the original issue here: https://groups.google.com/forum/#!topic/bazel-discuss/GWM6igeQJX4.

It appears that this commit: d06c276 introduced a --copt that forces Xcode to recompile my applications even after building them on the command line using hazel build -c dbg src/main/myap.

My current work around is to use a Tusli version that is based on a commit prior to the one above.

I just cloned the repository and ran into 2 build errors when trying to build it using Xcode 8.2.1:

/Users/robbie/tulsi/src/TulsiGenerator/BazelLocator.swift:27:12: 'NSUserDefaults' has been renamed to 'UserDefaults'
/Users/robbie/tulsi/src/TulsiGenerator/TulsiProject.swift:108:62: Missing argument label 'workspaceRoot:' in call

The Getting Started docs or landing page are missing a link to download the Tulsi app or instructions to install it.

The instructions can be found in the project's README

hi all

I was stoped by step: 4. Create project generator configs ~ step: The Tulsi generator configuration editor in this tutorial: https://tulsi.bazel.build/docs/gettingstarted.html

in the tutorial, it said "Clicking the "+" button will allow you to add new generator configs. Double clicking on an existing config will allow you to edit it, and the "-" button can be used to permanently delete previously created configs."

however when I Clicked the "+" button, it came out this:

I so confuse about how can I do after this window came out?

thanks advance

This is specifically for the direct debug prefix map solution that exists in Tulsi open source, today. Currently, it doesn't understand how to obtain paths generated by the new Bazel sandbox for Darwin, so breakpoint level debugging doesn't work for open source Tulsi.

Confirmed the problem with the iOS sample app built via https://github.com/nglevin/bazel/blob/fe4936031e38dd33687261334b2225224e96c430/site/docs/tutorial/ios-app.md with Bazel 0.15.0-homebrew.

I believe this would be fixed by porting the "normalized path" debug prefix map solution to open source Tulsi and bazel_build.py, which requires a wrapped_clang update.

I filed a follow up for Bazel, which needs a specific feature flag ported to open source for the normalized, dotted path debug-prefix-map solution to work as well; bazelbuild/bazel#5545

I generated a simple ios project with tulsi. I have a single main.swift file, and put a breakpoint in it. The debugger doesn't stop on this breakpoint, but the debugger was attached correctly because I could pause the app.

The dsym patcher is invoked with:

['/Users/robbertvanginkel/test/.tulsi/Utils/post_processor', '-d', '-v', '/Users/robbertvanginkel/Library/Developer/Xcode/DerivedData/App-fbkovlbzufvrizfxxpeuwgmqyffl/Build/Products/Debug-iphonesimulator/App.app.dSYM/Contents/Resources/DWARF/App', '/private/var/tmp/_bazel_robbertvanginkel/44f6264deb03d7ebd91b8dc407ba5747/execroot/__main__', '/Users/robbertvanginkel/test/']

Inspecting the dsym, it looks like bazel is using a different sandboxed path for swift by default:

$ dwarfdump /Users/robbertvanginkel/Library/Developer/Xcode/DerivedData/App-fbkovlbzufvrizfxxpeuwgmqyffl/Build/Products/Debug-iphonesimulator/App.app.dSYM | less
...
AT_name( "/private/var/tmp/_bazel_robbertvanginkel/44f6264deb03d7ebd91b8dc407ba5747/bazel-sandbox/be16c42f-4eac-4d28-b9b2-5abccdd93664-20/execroot/__main__/main.swift" )
...

I added the flag --strategy=SwiftCompile=standalone to the compile options, and then the patcher seems to correctly replace the path, which makes the breakpoint work.

Hi! Whenever I'm running a test target generated by Tulsi (from an ios_test rule), any breakpoints set in Xcode are never hit.

Even if I construct a test that sleeps for a few seconds, so I'm able to press the "pause" button on the debug pane, the test does not break when clicking on that button.

#import <XCTest/XCTest.h>

@interface SlowTests : XCTestCase

@end

@implementation SlowTests

- (void)testSlow
{
    sleep(4);
    XCTFail(@"Breakpoints don't work");
}

@end

Do you have any idea what might cause this behavior, and how we can fix it?

I'm currently using the rules_apple rules with Tulsi to define our iOS application. Building and running on device works and creates a valid IPA but using archive seems to quickly produce an invalid archive.

Any ideas on how to address this?

While editing or creating Configs in Tulsi GUI app, the last step where the Source targets are created is often super slow right before it loads the list of possible source targets. The spinner sometimes keeps spinning like... forever. Is this a known issue?

Here is what it is doing in the background...

Running <abc_xyz>/bazel/bazel-bin/src/bazel --max_idle_secs=60 query '--override_repository=tulsi=<home_dir>/Library/Application Support/Tulsi/0.4.215728096.20181004/Bazel' --announce_rc --noimplicit_deps --order_output=no --noshow_loading_progress --noshow_progress buildfiles(deps(//:Albahaca)) --keep_going --output xml

Bazel version: (source built from) release-0.19.0
Tulsi version: 0.4.215728096.20181004

Issue:
I'm generating a project for an ios_application target using tulsi that contains asset catalogs (*.xcassets). XCode has it's own viewer that it uses to display assets catalogs but tulsi's project generation renders these as folders.

From looking at the same project in XCode we have a difference in the project.pbxproj file:

Expected:

013B60D31A8403AB009E4376 /* Media.xcassets in Resources */ = {isa = PBXBuildFile; fileRef = 687E20E719958518005B84C3 /* Media.xcassets */; };

Actual:

966FB6DE564D875600000000 /* Media.xcassets */ = {
  isa = PBXGroup;
  children = (
    /* files here */
   );
   path = Media.xcassets;
   sourceTree = "<group>";
};

As you can see, XCode modifies it's project file to represent asset catalogs as PBXBuildFile objects vs PBXGroup. Resolving this should address the issue.

It would be awesome if Tulsi shipped a BUILD file in its repository so that we could run the code generator directly from a Bazel target, such as when new files are added to a project.

Perhaps it could build only the command line version of Tulsi?

They get set to the path "../Foo" instead of "bazel-projname/external/Foo". Looks like there's some support in tulsi for detecting external projects and even renamiong the group to be pretty like @Foo/ in xcode, but it doesn't appear to be working.

This can be reproduced in this project/sha (tulsiproj included) mikelikespie/swiftled@2c5f30e

Tulsi was updated in this recent commit to build with Bazel, but it has 2 issues.

1. It doesn't build with Xcode 10 like the previous version (0.4.216764214.20181011) used to.
2. The README.md still suggests to build it using Xcode project -- which is gone.

Am I missing something? If it's still a work-in-progress, I can help.
@reinhillmann @dierksen @DavidGoldman

Hey, I just tried a clean build and got a few errors all on the same function createLogFile.

EventLogger.swift:60:7: error: non-void function should return a value
EventLogger.swift:74:9: error: non-void function should return a value
EventLogger.swift:86:11: error: instance member 'logFile' cannot be used on type 'EventLogger'
EventLogger.swift:89:7: error: non-void function should return a value

I don't really know Swift but it seems like nil was supposed to be returned for the "non-void" errors and that self should not be accessed in that function as it is static for the other error.

Great job with Bazel and Tulsi btw.

Xcode 9.2
macOS 10.12.6

I'm trying to use the latest bazel MacOS rules and running into issues.
The first one is the following error produced during builds in Xcode:

:: error: Failed to extract Authority from Executable=/Users/benvanik/Library/Developer/Xcode/DerivedData/xrtl-cjlbibwnoyhiwycwlchzxhjarjqp/Build/Products/__TulsiTestRunner_Debug/arena_test_macos_xctest.xctest/Contents/MacOS/arena_test_macos_xctest

The binary does not have 'Authority':

codesign -dv --verbose=4 /Users/benvanik/Library/Developer/Xcode/DerivedData/xrtl-cjlbibwnoyhiwycwlchzxhjarjqp/Build/Products/__TulsiTestRunner_Debug/arena_test_macos_xctest.xctest/Contents/MacOS/arena_test_macos_xctest
Executable=/Users/benvanik/Library/Developer/Xcode/DerivedData/xrtl-cjlbibwnoyhiwycwlchzxhjarjqp/Build/Products/__TulsiTestRunner_Debug/arena_test_macos_xctest.xctest/Contents/MacOS/arena_test_macos_xctest
Identifier=com.xrtl.foo
Format=bundle with Mach-O thin (x86_64)
CodeDirectory v=20100 size=4381 flags=0x2(adhoc) hashes=132+3 location=embedded
OSPlatform=36
OSSDKVersion=658432
OSVersionMin=658432
Hash type=sha256 size=32
CandidateCDHash sha256=42c3ee4af649f8c8e3da2c4fb69b67be52c6dc09
Hash choices=sha256
Page size=4096
CDHash=42c3ee4af649f8c8e3da2c4fb69b67be52c6dc09
Signature=adhoc
Info.plist entries=15
TeamIdentifier=not set
Sealed Resources version=2 rules=13 files=0
Internal requirements count=0 size=12

This is produced with a check in Tulsi here:

If I add this fallback when it's trying to print the error the build succeeds and the test runs:

        self.attributes[attribute] = '-'

I'm not sure the root cause or reason why the Authority expectation exists. Would such a fallback for missing Authority be acceptable for a PR?

Hi!

I couldn't get debugging to work out of the box in a full bazel project, so I created a simple pure Objective-C sample project and Xcode is not associating breakpoints with the source files in both lldbinit and dsym+dwarfpatcher cases.

It was my assumption that this was consistently working, so I was surprised to see it not working for me. Maybe I've configured something improperly?

I uploaded a project that reproduces the issue:
https://github.com/bkase/debugging-tulsi-broken

Thanks!

The source filters are prefixed with @ instead of being mapped to external

After cloning from master and running bazel build ... I get the following error:

src/TulsiGenerator/BazelAspectInfoExtractor.swift:43:42: error: use of undeclared type 'Process'
  private typealias CompletionHandler = (Process, String) -> Void

bazel version
Build label: 0.18.0-homebrew
Build target: bazel-out/darwin-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Tue Oct 16 15:57:40 2018 (1539705460)
Build timestamp: 1539705460
Build timestamp as int: 1539705460

ios version 10.13.3

Tulsi provides a command line option to pass additional build options on the command line. It is unclear if it is possible or how to pass multiple options. For example, we would like to pass both "--noexperimental_enable_objc_cc_deps" and "--define=xyz". It appears that the buildOptions are stored internally in as a string. Passing --build-options "--noexperimental_enable_objc_cc_deps --define=xyz", for example, does not work.

--experimental_enable_objc_cc_deps is a default option in projects generated by Tulsi. When I attempt to build the Xcodeproj it generates, it fails with the error "No toolchain found for cpu 'watchos_i386'" This issue appears to be the same as is written up here.

For now, it is possible to pass in --noexperimental_enable_objc_cc_deps as a workaround, but that won't be possible when generating a workspace where we need ObjC libraries to depend on cc_libraries.

In this commit, Fix issues with discovering external directories, the external target source filters are disabled.

+    // Hardcode in an inclusion for "external/" directory as it is supported natively by Bazel.
     let recursiveFilters = Set<String>(pathFilters.filter({ $0.hasSuffix("/...") }).map() {
        $0.substring(to: $0.characters.index($0.endIndex, offsetBy: -3))		        $0.substring(to: $0.characters.index($0.endIndex, offsetBy: -3))
-    })		 
+    }).union(["external/"])

Previously, I used to be able select which external targets I wanted in the Xcode project. Now the preference is ignored. This was useful for keeping project size reasonable.

Our team uses a .bazelrc which includes build and test flags. Tulsi picks up the .bazelrc file when pointed to in 'Build' startup options with a --bazelrc=.bazelrc but it is not reading --test-env flags and not setting them on test targets. As a result, the flags might be used during bazel build in Xcode but they are not effective while running individual tests from Xcode.

@DavidGoldman @reinhillmann @dierksen, Can you please take a look?