On 08/08/2016 02:04 PM, Brad King wrote:
> Ninja: Use full path for all source files
> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=955c2a63
Unfortunately using an absolute path triggers a ninja limitation and
breaks rebuilds in some cases. See the issue [1] and MR to revert
the change [
Thanks. But to address Florent's concern, are there tests that cover the
windows command line limit?
I guess to test if this breaks we'd need a source file whose compile
command is under the limit if using relative path,
but over the limit if using absolute path.
On Mon, Aug 8, 2016 at 11:04 AM, B
On 08/08/2016 01:42 PM, Chaoren Lin wrote:
>> I don't think this hunk is needed anymore, correct?
>
> That hunk is the opposite now
Oops, right. That actually fixes the existing RC bug I mentioned
earlier in this thread.
With your patch the use of IN_ABS breaks builds with spaces in the
path.
On 08/08/2016 09:19 AM, Ben Boeckel wrote:
> On Sun, Aug 07, 2016 at 04:54:52 +0200, Florent Castelli wrote:
>> I'd say that you shouldn't do this unless you have tested it extensively
>> with very long command lines, making sure that there is a response file
>> fallback if it grows too much.
>>
> I don't think this hunk is needed anymore, correct?
That hunk is the opposite now, or does RC still need that hack for some
reason?
On Mon, Aug 8, 2016 at 10:41 AM, Brad King wrote:
> On 08/05/2016 07:51 PM, Chaoren Lin wrote:
> > - std::string const sourceFileName =
> > -language == "RC
On 08/05/2016 07:51 PM, Chaoren Lin wrote:
> - std::string const sourceFileName =
> -language == "RC" ? source->GetFullPath() :
> this->GetSourceFilePath(source);
> + std::string const sourceFileName = this->GetSourceFilePath(source);
I don't think this hunk is needed anymore, correct?
Tha
On Sun, Aug 07, 2016 at 04:54:52 +0200, Florent Castelli wrote:
> I'd say that you shouldn't do this unless you have tested it extensively
> with very long command lines, making sure that there is a response file
> fallback if it grows too much.
> There are issues in CMake already on Windows with
I'd say that you shouldn't do this unless you have tested it extensively
with very long command lines, making sure that there is a response file
fallback if it grows too much.
There are issues in CMake already on Windows with long command lines and
having even longer ones is not going to help.
From: Chaoren Lin
This is consistent with the behavior of the Makefile generators.
Relative paths are difficult for an IDE to parse the output of a build
error.
---
Source/cmNinjaTargetGenerator.cxx | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Source/cmNinjaTargetGen
> What about instead of "cd path && ninja", using "ninja -C path"?
I suppose we can also change "cmake --build path", to use "ninja -C path"
instead of "cd path && ninja",
but making ninja always use full paths for source files would have these
benefits:
1. consistency with make (as pointed ou
On Wed, Aug 03, 2016 at 11:11:45 -0700, Chaoren Lin wrote:
> Also, in the case of vim, the makeprg is user-supplied, so vim has no idea
> that it contains a path.
What about instead of "cd path && ninja", using "ninja -C path"?
--Ben
--
Powered by www.kitware.com
Please keep messages on-topic
> If you know /path/to/build why not just interpret relative paths with
> respect to it as a heuristic? If the paths exist then use them.
It's... a bit complicated. Our IDE (Android Studio) calls another build
system (Gradle) which in turn calls CMake to trigger the build. So the IDE
itself doesn
On 08/02/2016 04:42 PM, Chaoren Lin wrote:
> Our IDE uses "cmake --build /path/to/build" to invoke the build,
> so that we only have to deal with CMake and not the underlying build system.
If you know /path/to/build why not just interpret relative paths with
respect to it as a heuristic? If the p
The relative path is used whenever the build directory is under the source
directory (e.g., under src/build/), so it could still be out of source.
> FWIW, I haven't encountered any problems with Vim's :make with CMake's
> generated Ninja files in out-of-source builds for in-source or generated
> f
On Tue, Aug 02, 2016 at 11:11:44 -0700, Chaoren Lin via cmake-developers wrote:
> Similarly, the :make command in vim will have no knowledge of build.gradle,
> and only tries to parse the build errors directly.
FWIW, I haven't encountered any problems with Vim's :make with CMake's
generated Ninja
On 08/02/2016 02:11 PM, Chaoren Lin wrote:
> Would changing ConvertToNinjaPath to output absolute paths paths work?
No, that will make all paths absolute. Ninja's design is pretty clear
in that it prefers canonical relative paths when possible.
Note that the conversion to a relative path by Con
> Ninja always uses the location of the build.ninja file as
> the current working directory, so an IDE that sees a relative
> path in an error message can interpret it relative to that.
Our IDE has no knowledge of the build.gradle file let alone where it is
located, it just sees the build output a
On 08/02/2016 01:08 PM, Brad King wrote:
> Ninja: Use full path for all source files
> https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d867f8a0
I had to revert that because it causes the Qt*Autogen tests to
fail. Also it may break builds on Windows.
There are multiple problems:
* ConvertT
On 07/29/2016 05:44 PM, Chaoren Lin via cmake-developers wrote:
> From: Chaoren Lin
>
> Relative paths are difficult for an IDE to parse the output of
> a build error.
Thanks, applied:
Ninja: Use full path for all source files
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d867f8a0
This
From: Chaoren Lin
Relative paths are difficult for an IDE to parse the output of
a build error.
---
Source/cmNinjaTargetGenerator.cxx | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/Source/cmNinjaTargetGenerator.cxx
b/Source/cmNinjaTargetGenerator.cxx
index 855a243..7849c5
20 matches
Mail list logo
