{"action":"created","issue":{"url":"https://api.github.com/repos/martine/ninja/issues/977","labels_url":"https://api.github.com/repos/martine/ninja/issues/977/labels{/name}","comments_url":"https://api.github.com/repos/martine/ninja/issues/977/comments","events_url":"https://api.github.com/repos/martine/ninja/issues/977/events","html_url":"https://github.com/martine/ninja/issues/977","id":89851754,"number":977,"title":"Relative subninja paths don't resolve","user":{"login":"Qix-","id":885648,"avatar_url":"https://avatars.githubusercontent.com/u/885648?v=3","gravatar_id":"","url":"https://api.github.com/users/Qix-","html_url":"https://github.com/Qix-","followers_url":"https://api.github.com/users/Qix-/followers","following_url":"https://api.github.com/users/Qix-/following{/other_user}","gists_url":"https://api.github.com/users/Qix-/gists{/gist_id}","starred_url":"https://api.github.com/users/Qix-/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Qix-/subscriptions","organizations_url":"https://api.github.com/users/Qix-/orgs","repos_url":"https://api.github.com/users/Qix-/repos","events_url":"https://api.github.com/users/Qix-/events{/privacy}","received_events_url":"https://api.github.com/users/Qix-/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":4,"created_at":"2015-06-21T02:31:37Z","updated_at":"2015-06-21T05:30:12Z","closed_at":null,"body":"I would attempt a PR for this, but I'm not entirely sure this is a bug or if it's intended.\r\n\r\nWhen including a subninja, I get\r\n\r\n> ninja: error: 'mod.c', needed by 'mod.o', missing and no known rule to make it\r\n\r\nalthough running ninja directly in that directory works just fine. Under the suspicion that relative paths may be to blame, I copied the project structure to a new directory, prepended each input/output with the absolute path, and ran ninja from the parent directory (containing the `build.ninja` that `subninja`'d the module). It built just fine.\r\n\r\nIs this suggesting we should be generating our ninja configurations with absolute paths? This has a lot of problems, along with the fact not every generator I've seen does this. Further, the documentation doesn't make a distinction, and Ninja runs just fine otherwise.\r\n\r\nI want to err on the side of *it's a bug*, but I feel like a PR that does runtime path canonicalization might introduce a performance hit (though I'm waving my hands here without any benchmarks to back up that suspicion)."},"comment":{"url":"https://api.github.com/repos/martine/ninja/issues/comments/113865255","html_url":"https://github.com/martine/ninja/issues/977#issuecomment-113865255","issue_url":"https://api.github.com/repos/martine/ninja/issues/977","id":113865255,"user":{"login":"Qix-","id":885648,"avatar_url":"https://avatars.githubusercontent.com/u/885648?v=3","gravatar_id":"","url":"https://api.github.com/users/Qix-","html_url":"https://github.com/Qix-","followers_url":"https://api.github.com/users/Qix-/followers","following_url":"https://api.github.com/users/Qix-/following{/other_user}","gists_url":"https://api.github.com/users/Qix-/gists{/gist_id}","starred_url":"https://api.github.com/users/Qix-/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Qix-/subscriptions","organizations_url":"https://api.github.com/users/Qix-/orgs","repos_url":"https://api.github.com/users/Qix-/repos","events_url":"https://api.github.com/users/Qix-/events{/privacy}","received_events_url":"https://api.github.com/users/Qix-/received_events","type":"User","site_admin":false},"created_at":"2015-06-21T05:30:12Z","updated_at":"2015-06-21T05:30:12Z","body":"That makes sense, though I still don't see much of a benefit (other than scope).\r\n\r\n> It's an interesting idea to combine ninja files generated by different generators (it sounds like that's what you want to do?)\r\n\r\nExactly. Being able to include Ninja itself as a submodule for my generator, and then another CMake project (which is configured to output Ninja build files), and then generating the Ninja config files for both and including them as `subninja`s in *my* project's `build.ninja` file in order to be able to build them as if they were on their own, but still allow my project to use their outputs (and thus their dependency graphs) in order to build the whole project at once.\r\n\r\nIf that makes sense. Immediate use-case that I see with my generator in particular is that it's borrowing a few concepts from Tup (which IIRC influenced some design decisions within Ninja itself) in that I can include N subprojects, all with their own `build.ninja` files, and then tap into their graphs to allow me to automatically construct a much larger dependency graph.\r\n\r\nI personally think that'd make `subninja` a whole lot more useful, though I could see it being a breaking change. However, I don't see a way around this unless 1) I modify the dependencies' `build.ninja` files with a patch or 2) sacrifice the ability to harness the dependencies' dependency graphs.\r\n\r\nThoughts?"}}