[cmake-developers] [PATCH] Tests: Refactor testing of extra generators.
From: Chaoren Lin
Use a loop instead of repeating the same thing multiple times.
---
Tests/CMakeLists.txt | 77
1 file changed, 30 insertions(+), 47 deletions(-)
diff --git a/Tests/CMakeLists.txt b/Tests/CMakeLists.txt
index 6f1805b..c119cfd 100644
--- a/Tests/CMakeLists.txt
+++ b/Tests/CMakeLists.txt
@@ -569,60 +569,43 @@ if(BUILD_TESTING)
ADD_LINK_FLAGS_TEST(mod_flags_config dll_flags_config)
ADD_LINK_FLAGS_TEST(exe_flags_config mod_flags_config)
- # If we are running right now with a UnixMakefiles based generator,
+ # If we are running right now with a Unix Makefiles or Ninja based generator,
# build the "Simple" test with the ExtraGenerators, if available
# This doesn't test whether the generated project files work (unfortunately),
# mainly it tests that cmake doesn't crash when generating these project
files.
- if(${CMAKE_GENERATOR} MATCHES "Unix Makefiles" OR ${CMAKE_GENERATOR}
MATCHES "KDevelop")
+ if(${CMAKE_GENERATOR} MATCHES "Unix Makefiles" OR ${CMAKE_GENERATOR} MATCHES
"Ninja")
+
# check which generators we have
execute_process(COMMAND ${CMAKE_CMAKE_COMMAND} --help
OUTPUT_VARIABLE cmakeOutput ERROR_VARIABLE cmakeOutput)
-# check for the Eclipse generator
-if ("${cmakeOutput}" MATCHES Eclipse)
- add_test(Simple_EclipseGenerator ${CMAKE_CTEST_COMMAND}
- --build-and-test
- "${CMake_SOURCE_DIR}/Tests/Simple"
- "${CMake_BINARY_DIR}/Tests/Simple_EclipseGenerator"
- --build-two-config
- --build-generator "Eclipse CDT4 - Unix Makefiles"
- --build-generator-platform "${CMAKE_GENERATOR_PLATFORM}"
- --build-generator-toolset "${CMAKE_GENERATOR_TOOLSET}"
- --build-project Simple
- --build-options ${build_options}
- --test-command Simple)
- list(APPEND TEST_BUILD_DIRS
"${CMake_BINARY_DIR}/Tests/Simple_EclipseGenerator")
-endif ()
-# check for the CodeBlocks generator
-if ("${cmakeOutput}" MATCHES CodeBlocks)
- add_test(Simple_CodeBlocksGenerator ${CMAKE_CTEST_COMMAND}
- --build-and-test
- "${CMake_SOURCE_DIR}/Tests/Simple"
- "${CMake_BINARY_DIR}/Tests/Simple_CodeBlocksGenerator"
- --build-two-config
- --build-generator "CodeBlocks - Unix Makefiles"
- --build-generator-platform "${CMAKE_GENERATOR_PLATFORM}"
- --build-generator-toolset "${CMAKE_GENERATOR_TOOLSET}"
- --build-project Simple
- --build-options ${build_options}
- --test-command Simple)
- list(APPEND TEST_BUILD_DIRS
"${CMake_BINARY_DIR}/Tests/Simple_CodeBlocksGenerator")
-endif ()
-# check for the KDevelop3 generator
-if ("${cmakeOutput}" MATCHES KDevelop3)
- add_test(Simple_KDevelop3Generator ${CMAKE_CTEST_COMMAND}
- --build-and-test
- "${CMake_SOURCE_DIR}/Tests/Simple"
- "${CMake_BINARY_DIR}/Tests/Simple_KDevelop3Generator"
- --build-two-config
- --build-generator "KDevelop3 - Unix Makefiles"
- --build-generator-platform "${CMAKE_GENERATOR_PLATFORM}"
- --build-generator-toolset "${CMAKE_GENERATOR_TOOLSET}"
- --build-project Simple
- --build-options ${build_options}
- --test-command Simple)
- list(APPEND TEST_BUILD_DIRS
"${CMake_BINARY_DIR}/Tests/Simple_KDevelop3Generator")
-endif ()
+set(extraGenerators
+ "CodeBlocks"
+ "CodeLite"
+ "Eclipse CDT4"
+ "Kate"
+ "KDevelop3"
+ "Sublime Text 2")
+
+foreach(extraGenerator ${extraGenerators})
+ if ("${cmakeOutput}" MATCHES "${extraGenerator} - ${CMAKE_GENERATOR}")
+set(extraGeneratorTestName "Simple_${extraGenerator}Generator")
+string(REPLACE " " "" extraGeneratorTestName ${extraGeneratorTestName})
+
+add_test(${extraGeneratorTestName} ${CMAKE_CTEST_COMMAND}
+ --build-and-test
+ "${CMake_SOURCE_DIR}/Tests/Simple"
+ "${CMake_BINARY_DIR}/Tests/${extraGeneratorTestName}"
+ --build-two-config
+ --build-generator "${extraGenerator} - ${CMAKE_GENERATOR}"
+ --build-generator-platform "${CMAKE_GENERATOR_PLATFORM}"
+ --build-generator-toolset "${CMAKE_GENERATOR_TOOLSET}"
+ --build-project Simple
+ --build-options ${build_options}
+ --test-command Simple)
+list(APPEND TEST_BUILD_DIRS
"${CMake_BINARY_DIR}/Tests/${extraGeneratorTestName}")
+ endif ()
+endforeach(extraGenerator)
endif()
--
2.8.0.rc3.226.g39d4020
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.h
[cmake-developers] [PATCH] Fix RunCMake.Framework on case sensitive file systems.
The file is lowercase: Tests/RunCMake/Framework/osx.cmake
---
Tests/RunCMake/Framework/RunCMakeTest.cmake | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Tests/RunCMake/Framework/RunCMakeTest.cmake
b/Tests/RunCMake/Framework/RunCMakeTest.cmake
index d810283..eeea6f1 100644
--- a/Tests/RunCMake/Framework/RunCMakeTest.cmake
+++ b/Tests/RunCMake/Framework/RunCMakeTest.cmake
@@ -20,7 +20,7 @@ unset(RunCMake_TEST_OPTIONS)
set(RunCMake_TEST_BINARY_DIR ${RunCMake_BINARY_DIR}/OSXFrameworkLayout-build)
set(RunCMake_TEST_NO_CLEAN 1)
-set(RunCMake_TEST_OPTIONS
"-DCMAKE_TOOLCHAIN_FILE=${RunCMake_SOURCE_DIR}/OSX.cmake")
+set(RunCMake_TEST_OPTIONS
"-DCMAKE_TOOLCHAIN_FILE=${RunCMake_SOURCE_DIR}/osx.cmake")
file(REMOVE_RECURSE "${RunCMake_TEST_BINARY_DIR}")
file(MAKE_DIRECTORY "${RunCMake_TEST_BINARY_DIR}")
--
2.8.0.rc3.226.g39d4020
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Use full path for all source files in ninja build.
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, Brad King wrote: > 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. The reason is that Ninja handles quoting of paths when > replacing the `$in` placeholder but does nothing special for > `$IN_ABS`. CMake will have to generate the right path in the value. > > I've applied the patch with the appropriate modification for that: > > Ninja: Use full path for all source files > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=955c2a63 > > Thanks, > -Brad > > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Use full path for all source files in ninja build.
> 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" ? source->GetFullPath() : this->GetSourceFilePath( > source); > > + std::string const sourceFileName = this->GetSourceFilePath(source); > > I don't think this hunk is needed anymore, correct? > > Thanks, > -Brad > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Use full path for all source files in ninja build.
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/cmNinjaTargetGenerator.cxx
b/Source/cmNinjaTargetGenerator.cxx
index 855a243..5b4a55d 100644
--- a/Source/cmNinjaTargetGenerator.cxx
+++ b/Source/cmNinjaTargetGenerator.cxx
@@ -305,7 +305,7 @@ void cmNinjaTargetGenerator::WriteCompileRule(const
std::string& lang)
vars.RuleLauncher = "RULE_LAUNCH_COMPILE";
vars.CMTarget = this->GetGeneratorTarget();
vars.Language = lang.c_str();
- vars.Source = "$in";
+ vars.Source = "$IN_ABS";
vars.Object = "$out";
vars.Defines = "$DEFINES";
vars.Includes = "$INCLUDES";
@@ -529,8 +529,7 @@ void cmNinjaTargetGenerator::WriteObjectBuildStatement(
cmSourceFile const* source, bool writeOrderDependsTargetForTarget)
{
std::string const language = source->GetLanguage();
- std::string const sourceFileName =
-language == "RC" ? source->GetFullPath() : this->GetSourceFilePath(source);
+ std::string const sourceFileName = this->GetSourceFilePath(source);
std::string const objectDir =
this->ConvertToNinjaPath(this->GeneratorTarget->GetSupportDirectory());
std::string const objectFileName =
@@ -539,6 +538,7 @@ void cmNinjaTargetGenerator::WriteObjectBuildStatement(
cmSystemTools::GetFilenamePath(objectFileName);
cmNinjaVars vars;
+ vars["IN_ABS"] = source->GetFullPath();
vars["FLAGS"] = this->ComputeFlagsForObject(source, language);
vars["DEFINES"] = this->ComputeDefines(source, language);
vars["INCLUDES"] = this->GetIncludes(language);
--
2.8.0.rc3.226.g39d4020
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Let CMake know that clang uses the GCC toolchain.
Makes sense. Thank you. On Thu, Aug 4, 2016 at 6:53 AM, Brad King wrote: > On 08/03/2016 03:22 PM, Chaoren Lin wrote: > >> It will take some investigation to decide how/whether to set SIMULATE_ID > >> to GNU. > > > > This seems like the right thing to do, and is more future proof than the > alternative. > > This patch may do it. > > ```patch > diff --git a/Modules/Compiler/Clang-DetermineCompilerInternal.cmake > b/Modules/Compiler/Clang-DetermineCompilerInternal.cmake > index 08c1230..a8ef61b 100644 > --- a/Modules/Compiler/Clang-DetermineCompilerInternal.cmake > +++ b/Modules/Compiler/Clang-DetermineCompilerInternal.cmake > @@ -12,4 +12,6 @@ set(_compiler_id_version_compute " > set(_compiler_id_simulate " > # if defined(_MSC_VER) > # define @PREFIX@SIMULATE_ID \"MSVC\" > +# elif defined(__GNUC__) > +# define @PREFIX@SIMULATE_ID \"GNU\" > # endif") > ``` > > However, I remember now why we didn't do this before. For MSVC, Clang > actually tries to look a lot like `cl`. It defines _MSC_VER to a > version matching the compiler's standard library. OTOH for GNU, Clang > is not trying to look like a specific version. It always defines > __GNUC__ to 4 and __GNUC_MINOR__ to 2, regardless of what standard > library is used. Essentially Clang is acting as a standalone compiler > that happens to use a GNU standard library as an implementation detail. > > Therefore I've decided to go with the direct approach. Please > try out this change: > > Ninja: Fix response file format for GNU-like Clang on Windows > https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=e555480c > > Thanks, > -Brad > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Use full path for all source files in ninja build.
> 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 out by Brad) 2. consistency regardless of where the build directory is located (in source, under source, or out of source) 3. all three ways of invoking the build would work for IDEs (cmake --build, cd && ninja, ninja -C), so future IDE writers won't run into the sample problem no matter which way they choose On Wed, Aug 3, 2016 at 1:12 PM, Ben Boeckel wrote: > 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 and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Let CMake know that clang uses the GCC toolchain.
> It will take some investigation to decide how/whether to set SIMULATE_ID
> to GNU.
This seems like the right thing to do, and is more future proof than the
alternative.
On Wed, Aug 3, 2016 at 5:56 AM, Brad King wrote:
> On 08/02/2016 06:59 PM, Chaoren Lin wrote:
> >> In the gcc-like variant the CMAKE_{C,CXX}_SIMULATE_ID
> >> should be detected as GNU and cause the existing code to work.
> >
> > Huh, it doesn't look like that variable is set automatically when using
> > clang with the gcc toolchain. Is that supposed to happen?
> > It should be set manually (say, in a toolchain file)?
>
> It is supposed to be detected automatically. Whenever Clang is detected
> on Windows the _SIMULATE_ID should be detected too. I found the problem.
> The simulate id detection is done here:
>
>
> https://gitlab.kitware.com/cmake/cmake/blob/v3.6.1/Modules/Compiler/Clang-DetermineCompilerInternal.cmake#L12-15
>
> and it only looks for MSVC. Grepping for SIMULATE_ID reveals that it is
> used for Intel and Clang but only ever detects when MSVC is simulated.
> All consuming code paths are interested in whether SIMULATE_ID==MSVC
> and otherwise assume GNU, except cmGlobalNinjaGenerator::EnableLanguage.
>
> It will take some investigation to decide how/whether to set SIMULATE_ID
> to GNU. Alternatively the corresponding test in the Ninja generator could
> be changed to look for `COMPILER_ID == Clang && SIMULATE_ID != MSVC`.
>
> -Brad
>
>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Use full path for all source files in ninja build.
> 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't see the build path, only the failure output. Also, in the case of vim, the makeprg is user-supplied, so vim has no idea that it contains a path. > Another approach is to use ConvertToNinjaPath for all the build.ninja > inputs and outputs on build statements but use something other than $in > for the source file on the compilation rule. Using an "IN_ABS = ..." > variable could achieve this. Thanks, I'll try this. On Wed, Aug 3, 2016 at 5:56 AM, Brad King wrote: > 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 paths exist then use them. > > > Maybe I can try to fix ninja to resolve paths before sending them to the > compiler. > > The ninja build tool itself does not have enough information to make > such a transformation. CMake does though. See below. > > > Or maybe just add a flag to ConvertToNinjaPath or something. > > ConvertToNinjaPath is called from several places that don't all know > whether the file they are passing is a source file for compilation > or not. > > Another approach is to use ConvertToNinjaPath for all the build.ninja > inputs and outputs on build statements but use something other than $in > for the source file on the compilation rule. Using an "IN_ABS = ..." > variable could achieve this. > > -Brad > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Let CMake know that clang uses the GCC toolchain.
> In the gcc-like variant the CMAKE_{C,CXX}_SIMULATE_ID
> should be detected as GNU and cause the existing code to work.
Huh, it doesn't look like that variable is set automatically when using
clang with the gcc toolchain. Is that supposed to happen?
It should be set manually (say, in a toolchain file)?
On Tue, Aug 2, 2016 at 10:08 AM, Brad King wrote:
> On 07/29/2016 05:44 PM, Chaoren Lin via cmake-developers wrote:
> > Clang on Windows uses the GCC toolchain, so we need to avoid using
> > backslashes for paths in response files.
> [snip]
> >strcmp(mf->GetSafeDefinition("CMAKE_C_COMPILER_ID"), "GNU") == 0
> ||
> >strcmp(mf->GetSafeDefinition("CMAKE_CXX_COMPILER_ID"), "GNU") ==
> 0 ||
> >strcmp(mf->GetSafeDefinition("CMAKE_C_SIMULATE_ID"), "GNU") == 0
> ||
> > - strcmp(mf->GetSafeDefinition("CMAKE_CXX_SIMULATE_ID"), "GNU") ==
> 0) {
>
> Clang on Windows also comes in a cl-like variant whose response files may
> need backslashes. In the gcc-like variant the CMAKE_{C,CXX}_SIMULATE_ID
> should be detected as GNU and cause the existing code to work. What goes
> wrong in your use case?
>
> Thanks,
> -Brad
>
>
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Use full path for all source files in ninja build.
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 > files (I almost never do in-source builds). Interesting. It appears that if you do :set makeprg=ninja\ -C\ /path/to/build | make then ninja will output this: > ninja: Entering directory `/path/to/build' and vim interprets that to be the working directory. However, if you use these: :set makeprg=cd\ /path/to/build\ &&\ ninja | make :set makeprg=cmake\ --build\ /path/to/build | make then the "Entering directory" line wouldn't appear, and vim won't know what to do. 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. Compilers know the absolute path to all the files in a translation unit > since the preprocessor was able to read them. They could be taught to > produce absolute paths in their error messages to work better for IDEs > regardless of how the build system invokes them. I would love to see this too, but it's much easier to fix the problem in one place (CMake, or even just Ninja), than to fix that for every compiler. Maybe I can try to fix ninja to resolve paths before sending them to the compiler. Or maybe just add a flag to ConvertToNinjaPath or something. On Tue, Aug 2, 2016 at 11:33 AM, Ben Boeckel wrote: > 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 files in out-of-source builds for in-source or generated > files (I almost never do in-source builds). > > --Ben > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] [PATCH] Use full path for all source files in ninja build.
> 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 and tries to located the mentioned files. Similarly, the :make command in vim will have no knowledge of build.gradle, and only tries to parse the build errors directly. Would changing ConvertToNinjaPath to output absolute paths paths work? On Tue, Aug 2, 2016 at 10:38 AM, Brad King wrote: > 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: > > * ConvertToNinjaPath does more than just relative path conversions. > It also converts slashes on Windows. Furthermore, it deals with > CMAKE_NINJA_OUTPUT_PATH_PREFIX, though that won't matter for > absolute paths. > > * Calls to AddAssumedSourceDependencies and HasCustomCommandOutput > later in cmNinjaTargetGenerator::WriteObjectBuildStatement expect > to be given paths that come out of ConvertToNinjaPath. > > * Ninja does not seem to be able to reconcile a dependency on > an absolute path with a build statement providing that path > by relative path. Custom commands that generate source files > list their outputs with ConvertToNinjaPath. > > Basically everything assumes that all paths written as inputs > or outputs of Ninja build statements have gone through the > ConvertToNinjaPath method. The special case for "RC" in the > existing code is likely buggy. > > 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. > > -Brad > > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [PATCH] Use full path for all source files in ninja build.
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..7849c5e 100644
--- a/Source/cmNinjaTargetGenerator.cxx
+++ b/Source/cmNinjaTargetGenerator.cxx
@@ -529,8 +529,7 @@ void cmNinjaTargetGenerator::WriteObjectBuildStatement(
cmSourceFile const* source, bool writeOrderDependsTargetForTarget)
{
std::string const language = source->GetLanguage();
- std::string const sourceFileName =
-language == "RC" ? source->GetFullPath() : this->GetSourceFilePath(source);
+ std::string const sourceFileName = source->GetFullPath();
std::string const objectDir =
this->ConvertToNinjaPath(this->GeneratorTarget->GetSupportDirectory());
std::string const objectFileName =
--
2.8.0.rc3.226.g39d4020
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] [PATCH] Let CMake know that clang uses the GCC toolchain.
Clang on Windows uses the GCC toolchain, so we need to avoid using
backslashes for paths in response files.
---
Source/cmGlobalNinjaGenerator.cxx | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/Source/cmGlobalNinjaGenerator.cxx
b/Source/cmGlobalNinjaGenerator.cxx
index 51175c7..776a44f 100644
--- a/Source/cmGlobalNinjaGenerator.cxx
+++ b/Source/cmGlobalNinjaGenerator.cxx
@@ -558,7 +558,12 @@ void cmGlobalNinjaGenerator::EnableLanguage(
strcmp(mf->GetSafeDefinition("CMAKE_C_COMPILER_ID"), "GNU") == 0 ||
strcmp(mf->GetSafeDefinition("CMAKE_CXX_COMPILER_ID"), "GNU") == 0 ||
strcmp(mf->GetSafeDefinition("CMAKE_C_SIMULATE_ID"), "GNU") == 0 ||
- strcmp(mf->GetSafeDefinition("CMAKE_CXX_SIMULATE_ID"), "GNU") == 0) {
+ strcmp(mf->GetSafeDefinition("CMAKE_CXX_SIMULATE_ID"), "GNU") == 0 ||
+ // Clang uses the GCC toolchain.
+ strcmp(mf->GetSafeDefinition("CMAKE_C_COMPILER_ID"), "Clang") == 0 ||
+ strcmp(mf->GetSafeDefinition("CMAKE_CXX_COMPILER_ID"), "Clang") == 0 ||
+ strcmp(mf->GetSafeDefinition("CMAKE_C_SIMULATE_ID"), "Clang") == 0 ||
+ strcmp(mf->GetSafeDefinition("CMAKE_CXX_SIMULATE_ID"), "Clang") == 0) {
this->UsingGCCOnWindows = true;
}
#endif
--
2.8.0.rc3.226.g39d4020
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake-developers
