I've reproduced this using top-of-tree swiftpm. There doesn't appear to be anything wrong with how the llbuild YAML file is produced; indeed, it does work fine the first time. Visual inspection of the .yaml also shows that it's correct.

Using dtruss on swift-build-tool, however, shows this, among other things:

 2906/0x2ab3b:  stat64("/private/tmp/2/my\\ swift\\ projects/myproject/Sources/main.swift\0", 0x7FFF514D3F68, 0x7FFF514D3B34)        = -1 Err#2

So there seems to be incorrect escaping going on inside of swift-build-tool.

The unit tests don't catch this because this only shows up when it's comparing the touched source file with what's in the database, and it seems that the unit tests only verify that building from clean works. We should add unit tests for iterative builds too.

Sending to llbuild.

@aciidb0mb3r

I did some investigation and it looks like the dependency parser is returning escaped paths for eg:

("/Users/aciid/mycode/my\\ swift\\ project/myproj/Sources/main.swift") 

which is being stored in the db.

What is the correct way to solve this? Should the parser return unescaped strings or Buildsystem should remove the escape char?

The parser for deps is supposed to handle this, it should return in in escaped strings. I could have sworn we had implementation and test cases for this. 🙁

Ankit: Since quotes and escapes are an artifact of the text-based file format, the parser should be interpreting them and returning unescaped strings.

PR #30

Great, thanks for the fix, Ankit. I'm sending this to Daniel to merge since it's in llbuild.

Fixed in 26206ba

Yay

Actually, that just fixes the makefile deps parsing issue... it doesn't look like that completely resolves this so I need to investigate further.

Never mind, it does resolve it, I just forgot my local toolchain doesn't automatically pick up my llbuild rebuilds.