[cmake-developers] FindProtobuf backward compatibility issue for PROTOBUF_IMPORT_DIRS

2016-07-29 Thread Konstantin Sinitsyn 
After recent changes in FindProtobuf.cmake protobuf_generate_cpp doesn't
take into account PROTOBUF_IMPORT_DIRS (in upper case) anymore.

The issue was introduced by this change:
http://public.kitware.com/pipermail/cmake-developers/2016-March/027910.html
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a7b09e7f

As far as I understand issue is caused by the fact that code that changes
uppercase to camelcase is executed only when we call find_package, but the
way it's sometimes used is

find_package(Protobuf REQUIRED)

set(PROTOBUF_IMPORT_DIRS ./includedir1)
protobuf_generate_cpp(SRCS1 HDRS1 PROTOS2)

set(PROTOBUF_IMPORT_DIRS ./includedir2)
protobuf_generate_cpp(SRCS2 HDRS2 PROTOS2)

set(PROTOBUF_IMPORT_DIRS ./includedir3)
protobuf_generate_cpp(SRCS3 HDRS3 PROTOS3)

But now protobuf_generate_cpp only looks at camel case variable.


Here's the patch to fix this:

diff --git a/Modules/FindProtobuf.cmake b/Modules/FindProtobuf.cmake
index c90a0a2..6c04de3 100644
--- a/Modules/FindProtobuf.cmake
+++ b/Modules/FindProtobuf.cmake
@@ -129,6 +129,10 @@ function(PROTOBUF_GENERATE_CPP SRCS HDRS)
 set(_protobuf_include_path -I ${CMAKE_CURRENT_SOURCE_DIR})
   endif()

+  if(DEFINED PROTOBUF_IMPORT_DIRS AND NOT DEFINED Protobuf_IMPORT_DIRS)
+set(Protobuf_IMPORT_DIRS ${PROTOBUF_IMPORT_DIRS})
+  endif()
+
   if(DEFINED Protobuf_IMPORT_DIRS)
 foreach(DIR ${Protobuf_IMPORT_DIRS})
   get_filename_component(ABS_PATH ${DIR} ABSOLUTE)
@@ -187,6 +191,10 @@ function(PROTOBUF_GENERATE_PYTHON SRCS)
 set(_protobuf_include_path -I ${CMAKE_CURRENT_SOURCE_DIR})
   endif()

+  if(DEFINED PROTOBUF_IMPORT_DIRS AND NOT DEFINED Protobuf_IMPORT_DIRS)
+set(Protobuf_IMPORT_DIRS ${PROTOBUF_IMPORT_DIRS})
+  endif()
+
   if(DEFINED Protobuf_IMPORT_DIRS)
 foreach(DIR ${Protobuf_IMPORT_DIRS})
   get_filename_component(ABS_PATH ${DIR} ABSOLUTE)

~
Konstantin
-- 

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] VS 2015, long command line in ResourceCompile invocation

2016-07-29 Thread Simon Richter 
Hi,

I have a build that fails with

C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(1320,5):
warning MSB6002: Die Befehlszeile f�r die RC-Aufgabe ist zu lang. Bei
Befehlszeilen mit mehr als 32000 Zeichen treten h„ufig Fehler auf.
Versuchen Sie, die Befehlszeile zu k�rzen, indem Sie den Aufruf von RC
in mehrere Aufrufe mit weniger Parametern pro Aufruf unterteilen.
[C:\Jenkins\workspace\windows-oce-msvc-head\build\release\cpu\x86\label\windows\adm\cmake\TKOffset\TKOffset.vcxproj]

C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets(1320,5):
error MSB6003: Die angegebene ausf�hrbare Datei der Aufgabe "rc.exe"
konnte nicht ausgef�hrt werden. Der Dateiname oder die Erweiterung ist
zu lang
[C:\Jenkins\workspace\windows-oce-msvc-head\build\release\cpu\x86\label\windows\adm\cmake\TKOffset\TKOffset.vcxproj]

The full build log is at

http://ci.kicad-pcb.org/job/windows-oce-msvc-head/build=release,cpu=x86,label=windows/6/consoleFull

Is there a way to make VS use a response file here?

   Simon



signature.asc
Description: OpenPGP digital signature
-- 

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.

2016-07-29 Thread Chaoren Lin via cmake-developers 
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.

2016-07-29 Thread Chaoren Lin via cmake-developers 
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

[cmake-developers] [ISSUE] Bump to 3.2 and continue...

2016-07-29 Thread Konstantin Podsvirov 
Hello CMake developers,

I found bug:

https://gitlab.kitware.com/cmake/cmake/issues/16220

I found it, but I do not want to deal with it ...

--
Regards,
Konstantin Podsvirov
-- 

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] cmake -E capabilities [attempt 2]

2016-07-29 Thread Tobias Hunger 
Hi Stephen,

thanks for taking the time to do such a thorough review!

I pushed an update that takes most of the feedback into account. Still at:

https://github.com/hunger/CMake/commits/cmake-capabilities

On Wed, Jul 27, 2016 at 1:11 AM, Stephen Kelly  wrote:
> Tobias Hunger wrote:
>
>> Did anyone find some time for a review yet?
>
> Hi Tobias,
>
> I had a look through this this evening. Thanks for working on this. The
> commit adding the functionality at the end looks much better after the extra
> generator refactoring.
>
> Here are some review notes:
>
> * That commit has a cmDefinitions include though that should be removed.

Gone.

> * There are also some methods that should be const

Added const to some of them:-) Hope I caught all.

> * and a whitespace change that should be squashed into the commit that
> introduces it

I used Utilities/Scripts/clang-format.bash to do the formatting, so
that should not be an issue. I just reran that on all commits. Maybe I
forgot it in a commit or something before.

> * The pretty-print flag should be removed. Aside from being a boolean trap,
> it creates a interface segregation principle violation. See eg

Removed, even though I find it really useful when testing cmake on
mac/windows. I do have all the small helper tools on Linux, but
usually not on windows/Mac.

> * The CMAKE_BUILD_WITH_CMAKE macro should be in cmcmd.cxx wrapping the
> capabilities handling:
>
> #if defined(CMAKE_BUILD_WITH_CMAKE)
> else if (args[1] == "capabilities") {
>   cmake cm;
>   std::cout << cm.ReportCapabilities();
>   return 0;
> }
> #endif

Why?

> That define should not be used in ReportCapabilities.

That define seems necessary to keep the bootstrap test running.

> * Splitting the 'CMake: Refactor ExtraGenerator registration' commit into
> multiple commits would make it more reviewable, and more bisectable in the
> future.

Sorry, this is what you will get from me: I have to start at some
place and meddle through till things work again. I have to back-track
often.

Basically I need to get some functionality implemented completely and
then test that. Only afterwards can I spend time on making the patches
pretty.

If that is not acceptable, then please feel free to do necessary
changes yourself.

> As it is, it is doing many different things, none of which are mentioned in
> the commit message, and some of which it probably shouldn't be doing.
>
> For example renaming GetExtraGeneratorName to
> GetExternalMakefileProjectGeneratorName is probably not needed. If you
> really want to do it, then it should be in its own commit with its own
> commit message which justifies the change. As it is, it adds noise to the
> big commit and makes it harder to review. Minimal is always better with
> commits which do refactoring like that.

I undid that change. That is one of the things that I originally
removed and then realized last minute that it is needed somehow. So I
added it, not realizing that I had removed similar functionality
earlier.

> A general good rule of thumb (which helps reviews, and makes things
> bisectable in the future) is to do one thing per commit.

I agree that this is the ideal we all should all strive for, but you
are not going to get that from me anytime soon. At least not in the
cmake codebase.

Best Regards,
Tobias
-- 

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