[cmake-developers] [CMake 0015969]: String property broken in cmake 3.5.0-rc2 with XCode

2016-02-10 Thread Mantis Bug Tracker

The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=15969 
== 
Reported By:A. Klitzing
Assigned To:
== 
Project:CMake
Issue ID:   15969
Category:   CMake
Reproducibility:always
Severity:   major
Priority:   normal
Status: new
== 
Date Submitted: 2016-02-11 02:58 EST
Last Modified:  2016-02-11 02:58 EST
== 
Summary:String property broken in cmake 3.5.0-rc2 with XCode
Description: 
We build our application for iOS with cmake and iOS toolchain file [1].

We pass some strings with "-D" property to the compiler. In cmake 3.5.0rc2 (rc1
not tested) the build will fail as the quotes of the strings are broken.

Same code works with cmake 3.4.1.


[1] https://github.com/cristeab/ios-cmake


Steps to Reproduce: 
1. cmake ../source -DCMAKE_BUILD_TYPE=release -DCMAKE_PREFIX_PATH=/[...]/dist
-DCMAKE_TOOLCHAIN_FILE=../source/cmake/iOS.toolchain.cmake -GXcode

2. xcodebuild -target install -configuration Release

3. Compiler failed


Additional Information: 
Snippets of compiler cmdline:
See at -DVERSION=


3.5.0-rc2:

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
-x c++ -arch armv7 [.] -std=c++11 -ObjC++ -fPIC
-DVERSION=\\1.6.3+5-default-53920e4f2686\\ -MMD -MT dependencies [...] -c
/.../src/main.cpp -o
/.../build/src/XYZ.build/Release-iphoneos/XYZ.build/Objects-normal/armv7/main.o



3.4.1:

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
-x c++ -arch armv7 [.] -std=c++11 -fPIC
-DVERSION=\"1.6.3+5-default-53920e4f2686\" -MMD -MT dependencies -c
/.../src/main.cpp -o
/.../build/src/XYZ.build/Release-iphoneos/XYZ.build/Objects-normal/armv7/main.o




We use a little wrapper for quoted strings as XCode, windres and other compilers
works different here.




FUNCTION(GET_QUOTED_STRING _dest _str _filename)
IF(CMAKE_GENERATOR STREQUAL Xcode)
SET(tmp_var "${_str}")
ELSEIF(NOT ${arg} MATCHES ".rc$")
SET(tmp_var \\"${_str}\\")
ELSE()
SET(tmp_var ${_str})
ENDIF()

SET(${_dest} ${tmp_var} PARENT_SCOPE)
ENDFUNCTION()

FUNCTION(ADD_STRING_DEFINITION _str _def)
IF(ARGN)
FOREACH(arg ${ARGN})
IF (${arg} MATCHES "^AppTargetName")
SET(ARG_TYPE TARGET)
ELSE()
SET(ARG_TYPE SOURCE)
ENDIF()

IF(NOT "${_str}" STREQUAL "")
GET_QUOTED_STRING(tmp_var ${_str} ${arg})
SET(tmp_var =${tmp_var})
ENDIF()

SET_PROPERTY(${ARG_TYPE} ${arg} APPEND_STRING PROPERTY 
COMPILE_FLAGS "
-D${_def}${tmp_var}")
ENDFOREACH()
ELSE()
IF(NOT "${_str}" STREQUAL "")
GET_QUOTED_STRING(tmp_var ${_str} ${arg})
SET(tmp_var =${tmp_var})
ENDIF()
ADD_DEFINITIONS(-D${_def}${tmp_var})
ENDIF()
ENDFUNCTION()

FUNCTION(ADD_DEFINITION _def)
ADD_STRING_DEFINITION("" ${_def} ${ARGN})
ENDFUNCTION()


##

PROJECT(XYZ VERSION 1.6.3 CXX)
SET(VERSION_MERCURIAL ${PROJECT_VERSION}+5-default-53920e4f2686)
ADD_STRING_DEFINITION(${VERSION_MERCURIAL} "VERSION" main.cpp)

== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-02-11 02:58 A. KlitzingNew Issue
==

-- 

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 Daemon

2016-02-10 Thread Tobias Hunger
Hi Stephen,

thanks for that information! Now I can finally fix the tests again
(and add a couple for the error cases
my branch handles;-).

I did play some more and implemented support for consistent progress
reporting and multiple protocol versions now in my branch at

https://github.com/hunger/CMake/tree/cmake-daemon

This unfortunately resulted in the interaction with the daemon changing a bit:-(

Upon start the daemon now sends:
{"supportedProtocolVersions":[{"major":0,"minor":1}],"type":"hello"}

You need to reply with something along the lines off:
{"type":"handshake", "protocolVersion": { "major": 0 }}

Daemon will respond with:
{"cookie":"","inResponseTo":"handshake","type":"reply"}

and listen for commands.

"version" will work at this point, but you need to do:

{"type":"initialize", "buildDirectory":"/some/build/dir"}

to trigger the actual parsing of data.

Afterwards all the usual commands are available as before.

I did not yet update the tests with this change, so I did not create a MR yet.

I also want to do some small (but intrusive) changes to how
cmServerResponse objects are created.

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


Re: [cmake-developers] Drop support for older Xcode versions?

2016-02-10 Thread Eric Wing
On 2/9/16, Davy Durham  wrote:
> I'll say that in my line of work, we still have to support OS X 10.6
> (just dropped 10.5 support) .. And we're doing this at Apple's own
> request/demand!  It's not fun.  I've had to hack tools around to get
> somewhat newer tool chains to continue to work, but it's been /great/
> that cmake hasn't been an obstacle in this endeavour.

Supporting 10.6...this is what I'm referring to. In Apple's world,
this means you are on 10.11 using Xcode 7.3 and setting the Deployment
target to 10.6.

I know for hard cases, it is never that simple, but do you really need
to be on 10.6 to develop for 10.6?

A corollary issue is that when you buy a new Mac, it usually can't
boot an operating system older than the one it shipped with. Backwards
compatibility is hard. This suggests two alternative paths:

- CMake archives older versions. You can always download the last
official supported version for CMake that runs on 10.6.

- We split the Xcode generators into per-version buckets. (Xcode 3, 4,
5, 6, 7). Work freezes on older generators after awhile, but hopefully
won't break. (Yeah, I know core CMake changes can get dicey, which is
why I didn't really want to suggest this.)

Anyway food for thought.
-- 

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 Daemon

2016-02-10 Thread Stephen Kelly
Tobias Hunger wrote:

> Hi Stephen,
> 
> stupid question: How do I run the server-mode autotests?
> 
> I just implemented a unified way to do progress reporting and want to
> make sure that did not break too much. Running
> Tests/Server/daemon-test.py manually works, but how do I run all those
> tests configured in the CMakeLists.txt? The builddirectory does not
> contain a Tests/Server directory to run make test in:-/

After building cmake, run 

 ctest -R Server 

in the build directory

Alternatively, cd to 

 Tests/Server 

in the source directory and 

 mkdir build
 cd build
 cmake ..

The tests are run at cmake time.

Thanks,

Steve.


-- 

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 Daemon

2016-02-10 Thread Tobias Hunger
Hi Stephen,

stupid question: How do I run the server-mode autotests?

I just implemented a unified way to do progress reporting and want to
make sure that did not break too much. Running
Tests/Server/daemon-test.py manually works, but how do I run all those
tests configured in the CMakeLists.txt? The builddirectory does not
contain a Tests/Server directory to run make test in:-/

Best Regards,
Tobias


On Wed, Feb 10, 2016 at 12:44 AM, Stephen Kelly  wrote:
> Stephen Kelly wrote:
>
>> Tamás Kenéz wrote:
>>
>>> That's great and really does open a new world for IDEs!
>>
>> Thanks! Let's see if the interest grows.
>>
>> I've just pushed the daemon code here:
>>
>>  https://github.com/steveire/cmake/tree/cmake-daemon
>
> Tobias made a pull request there. Rather than review it there, I will review
> it here for visibility.
>
>  https://github.com/steveire/CMake/pull/2
>
> The branch is quite it hard to review, or even to see the particular
> changes, due to large commits and diff noise. If the Daemon reaches a level
> of completeness that it could be upstreamed (See
>
>  http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15740
>
> ) then these commits (including all of my commits on the branch) would have
> to be rewritten, split, made reviewable etc making heavy use of `rebase -i`.
>
> In a way, we don't have to do that now, but I'm also not very enthusiastic
> about making the `cmake-daemon` branch commits unreadable. I would add your
> commits to the branch if they we split and in the appropriate place (eg,
> with the cmServerProtocol0_1 change early in the cmake-daemon branch).
>
> The changes in your branch are good and useful to more than just QtCreator.
>
> Things that I like in your branch:
>
> * Explicit cmServerRequest and cmServerResponse APIs, which enforce the type
> and cookie consistency.
> * Returning cmServerResponse objects from the cmServerProtocol instead of
> invoking the server from the cmServerProtocol.
> * A way to version the protocol in a future-proof way with C++ classes.
> * Implementation of daemon and protocol error messaging infrastructure.
> (Reporting errors from cmake code requires other refactoring:
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15607/focus=15636)
>
> So I think that is progress!
>
> Thanks,
>
> Steve.
>
>
>
> --
>
> 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
-- 

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] Changes for v3.5.0

2016-02-10 Thread Alan W. Irwin

On 2016-02-10 09:16-0500 Brad King wrote:


On 02/10/2016 05:34 AM, Bartosz Kosiorek wrote:

I have great news.
With Nighly Build 3.5.20160208 the regression was gone


Great, thanks for testing this!


I got curious about how this affected the timing of configuration of
the PLplot build so here are my results for that where in all cases I
am taking timing numbers from the second run of cmake (starting with
an empty build tree each time cmake is invoked) to account for all
speed gains from ccache and memory caching.  All CMake versions used
below were built by me on Linux (Debian jessie) with the bootstrap
method using export CFLAGS='-O3' export CXXFLAGS='-O3'.  So this speed
test between the various CMake versions should be a reasonably level
playing field.

Time required to configure PLplot with various versions of cmake:

3.3.2:
real0m15.678s
user0m11.472s
sys 0m2.432s

3.4.3:
real0m16.351s
user0m11.988s
sys 0m2.468s

3.5.0-rc2 (that tagged version from the git release branch this morning)
real0m16.167s
user0m11.812s
sys 0m2.568s

The 0.7 second increase in real time between 3.3.2 and 3.4.3 likely
indicates a small (~4 per cent) but acceptable systematic regression
in efficiency between those two versions. However, the 0.2 second
decrease in real time between 3.4.3 and 3.5.0-rc2 is likely close to
the measurement errors.  Nevertheless, that result is consistent with
Bartosz's result that the original large regression in efficiency he found
for 3.5.0-rc1 compared to prior versions has now been completely
solved for 3.5.0-rc2.

My thanks to Bartosz for finding this efficiency regression for
3.5.0-rc1, and my thanks to Brad for fixing it for 3.5.0-rc2.

Alan
__
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__

Linux-powered Science
__
--

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] Changes for v3.5.0

2016-02-10 Thread Robert Maynard
CMake 3.5.0-rc2 has been released and includes these performance fixes.

On Wed, Feb 10, 2016 at 9:16 AM, Brad King  wrote:
> On 02/10/2016 05:34 AM, Bartosz Kosiorek wrote:
>> I have great news.
>> With Nighly Build 3.5.20160208 the regression was gone
>
> Great, thanks for testing 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
-- 

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] [ANNOUNCE] CMake 3.5.0-rc2 now ready for testing!

2016-02-10 Thread Robert Maynard
I am proud to announce the second CMake 3.5 release candidate.

Sources and binaries are available at:
  https://cmake.org/download/

Documentation is available at:
  https://cmake.org/cmake/help/v3.5

Release notes appear below and are also published at
  https://cmake.org/cmake/help/v3.5/release/3.5.html

Some of the more significant features of CMake 3.5 are:

* The precompiled Windows binary provided on "cmake.org" is now a
  ".msi" package instead of an installer executable.  One may need to
  manually uninstall CMake versions lower than 3.5 before installing
  the new package.

* The "cmake-gui(1)" learned an option to set the toolset to be used
  with VS IDE and Xcode generators, much like the existing "-T" option
  to "cmake(1)".

* Find modules for Boost, FLEX, GTest, GTK2, PNG, TIFF, and XercesC
  now provide imported targets.

* The "FindOpenMP" module learned to support Clang.

* A new platform file for cross-compiling in the Cray Linux
  Environment to target compute nodes was added.  See Cross Compiling
  for the Cray Linux Environment for usage details.

* The "Compile Features" functionality is now aware of features
  supported by Clang compilers on Windows (MinGW).

* Support was added for the ARM Compiler (arm.com) with compiler id
  "ARMCC".

* When building for embedded Apple platforms like iOS CMake learned
  to build and install combined targets which contain both a device
  and a simulator build. This behavior can be enabled by setting the
  "IOS_INSTALL_COMBINED" target property.

* The "CPackDMG" module learned new variable to specify AppleScript
  file run to customize appearance of "DragNDrop" installer folder,
  including background image setting using supplied PNG or multi-
  resolution TIFF file.  See the "CPACK_DMG_DS_STORE_SETUP_SCRIPT" and
  "CPACK_DMG_BACKGROUND_IMAGE" variables.

Deprecated and Removed Features:

* The "CMakeForceCompiler" module and its macros are now deprecated.
  See module documentation for an explanation.

* The "cmake(1)" "-E time" command now properly passes arguments
  with spaces or special characters through to the child process.
  This may break scripts that worked around the bug with their own
  extra quoting or escaping.



CMake 3.5 Release Notes
***

Changes made since CMake 3.4 include the following.


New Features



GUI
---

* The "cmake-gui(1)" gained options to control warnings about
  deprecated functionality.

* The "cmake-gui(1)" learned an option to set the toolset to be used
  with VS IDE and Xcode generators, much like the existing "-T" option
  to "cmake(1)".

* The "cmake-gui(1)" gained a Regular Expression Explorer which may
  be used to create and evaluate regular expressions in real-time. The
  explorer window is available via the "Tools" menu.


Command-Line


* The "-Wdev" and "-Wno-dev" "cmake(1)" options now also enable and
  suppress the deprecated warnings output by default.

* The suppression of developer warnings as errors can now be
  controlled with the new "-Werror=dev" and "-Wno-error=dev"
  "cmake(1)" options.

* The "cmake(1)" "-E" command-line tools "copy",
  "copy_if_different", "copy_directory", and "make_directory" learned
  to support multiple input files or directories.


Commands


* The "cmake_parse_arguments()" command is now implemented natively.
  The "CMakeParseArguments" module remains as an empty placeholder for
  compatibility.

* The "install(DIRECTORY)" command learned to support "generator
  expressions" in the list of directories.


Variables
-

* The "CMAKE_ERROR_DEPRECATED" variable can now be set using the
  "-Werror=deprecated" and "-Wno-error=deprecated" "cmake(1)" options.

* The "CMAKE_WARN_DEPRECATED" variable can now be set using the
  "-Wdeprecated" and "-Wno-deprecated" "cmake(1)" options.


Properties
--

* The "VS_GLOBAL_" target property is now implemented for
  VS 2010 and above.  Previously it worked only in VS 2008 and below.


Modules
---

* The "ExternalProject" module learned a new "GIT_REMOTE_NAME"
  option to control the "git clone --origin" value.

* The "FindBoost" module now provides imported targets such as
  "Boost::boost" and "Boost::filesystem".

* The "FindFLEX" module "FLEX_TARGET" macro learned a new
  "DEFINES_FILE" option to specify a custom output header to be
  generated.

* The "FindGTest" module now provides imported targets.

* The "FindGTK2" module, when "GTK2_USE_IMPORTED_TARGETS" is
  enabled, now sets "GTK2_LIBRARIES" to contain the list of imported
  targets instead of the paths to the libraries.  Moreover it now sets
  a new "GTK2_TARGETS" variable containing all the targets imported.

* The "FindOpenMP" module learned to support Clang.

* The "FindOpenSSL" module gained a new "OPENSSL_MSVC_STATIC_RT"
  option to search for libraries using the MSVC static runtime.

* The "FindPNG" module now provides imported targets.

* The "FindTIFF" module now provides imported targets.

* A

Re: [cmake-developers] [PATCH] FindProtobuf: prevent redundant PROTOBUF_LIBRARIES

2016-02-10 Thread Rolf Eike Beer
Am Mittwoch, 10. Februar 2016, 10:36:31 schrieb Antonio Perez Barrero:
> Before this change, the variable PROTOBUF_LIBRARIES might get redundant
> value for debug and optimized configurations, e.g.
> 'optimized;/usr/lib/libprotobuf.so;debug;/usr/lib/libprotobuf.so'
> ---
>  Modules/FindProtobuf.cmake | 18 ++
>  1 file changed, 6 insertions(+), 12 deletions(-)
> 
> diff --git a/Modules/FindProtobuf.cmake b/Modules/FindProtobuf.cmake
> index 2f13b09..57c6e62 100644
> --- a/Modules/FindProtobuf.cmake
> +++ b/Modules/FindProtobuf.cmake
> @@ -213,6 +213,8 @@ endif()
>  # Internal function: search for normal library as well as a debug one
>  #if the debug one is specified also include debug/optimized keywords
>  #in *_LIBRARIES variable
> +include(SelectLibraryConfigurations)

For modules that are part of CMake use

  include(${CMAKE_CURRENT_LIST_DIR}/SelectLibraryConfigurations.cmake)

This makes sure exactly the version of SLC the module was designed to use will 
be used, i.e. those shipped with the exact same version of CMake.

Greetings,

Eike

signature.asc
Description: This is a digitally signed message part.
-- 

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] Ninja and add_subdirectory EXCLUDE_FROM_ALL

2016-02-10 Thread Brad King
On 02/10/2016 10:57 AM, Charles Huet wrote:
> When using Unix Makefiles (or MSVC) this causes the subfolder to contain
> a new Makefile, allowing me to build easily the whole subdir.
> 
> I cannot find such a facility with Ninja

The Makefile generator naturally lays makefiles out with launch points
in each directory.  The Xcode generator and Visual Studio generators
generate projects that can be loaded in the respective IDEs for each
source directory with a project() command in its CMakeLists.txt file:

 
https://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmGlobalXCodeGenerator.cxx;hb=v3.4.3#l407
 
https://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/cmGlobalVisualStudio7Generator.cxx;hb=v3.4.3#l383

They contain the relevant subsets of the build system needed for their
subdirectories.  Currently the Ninja generator does not have this
feature.  It may be possible to add but would take some investigation
into how intrusive the changes would be.

-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] FindProtobuf: prevent redundant PROTOBUF_LIBRARIES

2016-02-10 Thread Brad King
On 02/10/2016 04:36 AM, Antonio Perez Barrero wrote:
> find_library(${name}_LIBRARY
[snip]
> +   select_library_configurations(${name})
> +   set(${name}_LIBRARY_DEBUG ${${name}_LIBRARY_DEBUG} PARENT_SCOPE)
> +   set(${name}_LIBRARY ${${name}_LIBRARY} PARENT_SCOPE)
> +   set(${name}_LIBRARIES ${${name}_LIBRARIES} PARENT_SCOPE)

Thanks.  IIRC select_library_configurations needs the two inputs
to be _LIBRARY_DEBUG and _LIBRARY_RELEASE.  We'll
have to change the first find_library call to use _RELEASE.
The whole block can be arranged in the form

 if(${name}_LIBRARY)
   set(${name}_LIBRARIES "${${name}_LIBRARY}")
 else()
   ...current block, but with _RELEASE name...
 endif()

in order to be compatible with build scripts that expect to
set just ${name}_LIBRARY in the cache.

-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] [CMake 0015968]: Ninja generator is non-deterministic

2016-02-10 Thread Mantis Bug Tracker

The following issue has been SUBMITTED. 
== 
https://public.kitware.com/Bug/view.php?id=15968 
== 
Reported By:Chris
Assigned To:
== 
Project:CMake
Issue ID:   15968
Category:   CMake
Reproducibility:always
Severity:   major
Priority:   high
Status: new
== 
Date Submitted: 2016-02-10 12:13 EST
Last Modified:  2016-02-10 12:13 EST
== 
Summary:Ninja generator is non-deterministic
Description: 
CMake's Ninja generator is non-deterministic on our project (LLVM). This is
trivially reproducible by configuring llvm into a clean directory multiple times
and comparing the results.

This is a very real problem for our project because the nondeterminism in the
generated ninja build seems to be the cause of non-determinism in our build
outputs. One of the important methods of compiler testing is what we call a
3-stage build. The process is basically:

(1) build clang
(2) use clang from step 1 to build clang again
(3) use clang from step 2 to build clang again
(4) ensure clang from step 2 and clang from step 3 are binary identical

Today this works using the CMake Unix Makefile generator, but not using the
Ninja generator. This issue reproduces on CMake 3.4.x and CMake 3.5.0 rc1. I
assume it probably goes back quite a long ways too.

Steps to Reproduce: 
mkdir scratch
cd scratch
cmake -G Ninja 
cp build.ninja ..
rm -rf
cmake -G Ninja 
diff build.ninja ../build.ninja
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-02-10 12:13 Chris  New Issue
==

-- 

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] Ninja and add_subdirectory EXCLUDE_FROM_ALL

2016-02-10 Thread Charles Huet
Hi,

I have a folder in my build that is added as such: "add_subdirectory(folder
EXCLUDE_FROM_ALL)"

When using Unix Makefiles (or MSVC) this causes the subfolder to contain a
new Makefile, allowing me to build easily the whole subdir.

I cannot find such a facility with Ninja, which is very annoying (since the
folder I add this way are demos, there are quite a lot of targets to build).

Am I missing something or is this a feature I could add ?

Best
-- 

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] C# support ready for review

2016-02-10 Thread Stuermer, Michael SP/HZA-ZSEP
Native C# support is ready for review. I split the patch in two parts:

part 1:

Some preparational stuff that does not really change or enable anything. 
Documentation and Test files as well as the required CMake module is added. The 
changes to existing code are small, only few methods in existing classes are 
added/changed. Changes to existing code should be easy to review in this part

part 2:

This contains the main work. Almost everything takes place within 
cmVisualStudio10TargetGenerator.


In addition to C# support three more target properties were introduced:

-   VS_USER_PROPS_CXX (allows use of custom .user.props MSBuild file in 
.vcxproj files)
-   VS_USER_PROPS_CSHARP (allows use of custom .user.props MSBuild file in 
.csproj files)
-   VS_DEBUGGER_WORKING_DIRECTORY (allows setting of debugger working 
directory in .vcxproj files)

I tested the features using Visual Studio 2010-2015 in 32/64 bit and everything 
works on my machine so far.

Please review/test/comment and give feedback what is necessary to get native C# 
support in upstream cmake.

best regards,
Michael






0001-prepared-C-support.patch
Description: 0001-prepared-C-support.patch


0002-implemented-C-support.patch
Description: 0002-implemented-C-support.patch
-- 

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] [CMake 0015967]: CMAKE_AUTOMOC + OBJECT library in a subdirectory -> Failing ninja builds

2016-02-10 Thread Mantis Bug Tracker

The following issue has been SUBMITTED. 
== 
https://cmake.org/Bug/view.php?id=15967 
== 
Reported By:Artur K.
Assigned To:
== 
Project:CMake
Issue ID:   15967
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2016-02-10 09:31 EST
Last Modified:  2016-02-10 09:31 EST
== 
Summary:CMAKE_AUTOMOC + OBJECT library in a subdirectory ->
Failing ninja builds
Description: 
Projects using this combination of features fail to build with:
"
Assembler messages:
Fatal error: can't create lib/CMakeFiles/*.dir: Is a directory
"

the same project works perfectly when a Makefile is generated.

Steps to Reproduce: 
1. Unpack the provided minimal project:
2. run `mkdir bld; cd bld; cmake -G "Ninja" ..; ninja`




Additional Information: 
ninja version = 1.6.0
qt5 version = 5.5.1
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-02-10 09:31 Artur K.   New Issue
2016-02-10 09:31 Artur K.   File Added: cmake_qt5_automoc_object.tar.gz 
  
==

-- 

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] Changes for v3.5.0

2016-02-10 Thread Brad King
On 02/10/2016 05:34 AM, Bartosz Kosiorek wrote:
> I have great news.
> With Nighly Build 3.5.20160208 the regression was gone

Great, thanks for testing 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


[cmake-developers] [CMake 0015966]: BundleUtilities unconditionally removes RPATH in copy_resolved_item_into_bundle

2016-02-10 Thread Mantis Bug Tracker

The following issue has been SUBMITTED. 
== 
https://cmake.org/Bug/view.php?id=15966 
== 
Reported By:Florian Apolloner
Assigned To:
== 
Project:CMake
Issue ID:   15966
Category:   CCMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2016-02-10 08:53 EST
Last Modified:  2016-02-10 08:53 EST
== 
Summary:BundleUtilities unconditionally removes RPATH in
copy_resolved_item_into_bundle
Description: 
copy_resolved_item_into_bundle always removes the RPATH for libraries copied
into the bundle:
https://github.com/Kitware/CMake/blob/0def7e6e70d809958cb605e93dbe3d02baf05265/Modules/BundleUtilities.cmake#L625


This is often fine, but if your libraries depend on other libraries which are
not available on the system, this will prevent the from getting found.

In my case it was app -> libQt5Core.so.5 -> libicu.so whereas libQt5Core.so.5
from the precompiled SDK has $ORIGIN as RPATH since libicu is shipped along with
it.

Could be just drop that check or make it configurable? 
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-02-10 08:53 Florian ApollonerNew Issue
==

-- 

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] [CMake 0015965]: D3DCOMPILER_XX.dll included by fixup_bundle

2016-02-10 Thread Mantis Bug Tracker

The following issue has been SUBMITTED. 
== 
https://cmake.org/Bug/view.php?id=15965 
== 
Reported By:Robin KERDILES
Assigned To:
== 
Project:CMake
Issue ID:   15965
Category:   CMake
Reproducibility:always
Severity:   trivial
Priority:   none
Status: new
== 
Date Submitted: 2016-02-10 07:26 EST
Last Modified:  2016-02-10 07:26 EST
== 
Summary:D3DCOMPILER_XX.dll included by fixup_bundle
Description: 
D3DCOMPILER_XX.dll is included by fixup_bundle when I resolve dependencies where
it should not because this is provided by system.

Steps to Reproduce: 
* Try to build a CMake project using directx libraries (at least linking to
d3dcompiler) and use fixup_bundle on executables.

Additional Information: 
* Windows 10 Pro 1511 (10.0.10586) x64
* Visual Studio Enterprise 2015 Update 1
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-02-10 07:26 Robin KERDILES New Issue
==

-- 

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 Daemon

2016-02-10 Thread Tobias Hunger
Hi Stephen,

I will then continue down that road.

Next steps are a way to consistently report progress as well as being
able to have several protocol versions at the same time and have a
client pick one.

I will just put them atop my current branch, as that is going to need
basically the same amount of retro-active integration into similar
places as the current changes.

I am not keen on doing that twice:-)

Best Regards,
Tobias

On Wed, Feb 10, 2016 at 12:44 AM, Stephen Kelly  wrote:
> Stephen Kelly wrote:
>
>> Tamás Kenéz wrote:
>>
>>> That's great and really does open a new world for IDEs!
>>
>> Thanks! Let's see if the interest grows.
>>
>> I've just pushed the daemon code here:
>>
>>  https://github.com/steveire/cmake/tree/cmake-daemon
>
> Tobias made a pull request there. Rather than review it there, I will review
> it here for visibility.
>
>  https://github.com/steveire/CMake/pull/2
>
> The branch is quite it hard to review, or even to see the particular
> changes, due to large commits and diff noise. If the Daemon reaches a level
> of completeness that it could be upstreamed (See
>
>  http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15740
>
> ) then these commits (including all of my commits on the branch) would have
> to be rewritten, split, made reviewable etc making heavy use of `rebase -i`.
>
> In a way, we don't have to do that now, but I'm also not very enthusiastic
> about making the `cmake-daemon` branch commits unreadable. I would add your
> commits to the branch if they we split and in the appropriate place (eg,
> with the cmServerProtocol0_1 change early in the cmake-daemon branch).
>
> The changes in your branch are good and useful to more than just QtCreator.
>
> Things that I like in your branch:
>
> * Explicit cmServerRequest and cmServerResponse APIs, which enforce the type
> and cookie consistency.
> * Returning cmServerResponse objects from the cmServerProtocol instead of
> invoking the server from the cmServerProtocol.
> * A way to version the protocol in a future-proof way with C++ classes.
> * Implementation of daemon and protocol error messaging infrastructure.
> (Reporting errors from cmake code requires other refactoring:
> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/15607/focus=15636)
>
> So I think that is progress!
>
> Thanks,
>
> Steve.
>
>
>
> --
>
> 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
-- 

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] Changes for v3.5.0

2016-02-10 Thread Bartosz Kosiorek
Good Morning/Evening.

I have great news.
With Nighly Build 3.5.20160208 the regression was gone, and the Generation
performance is almost the as with CMake 3.4.3.

Here are details:
Version 3.2.2
real2m0.780s
user1m55.704s
sys0m2.360s

Version 3.4.3
real1m30.223s
user1m24.816s
sys0m3.004s

Version 3.5.0rc1
real6m20.086s
user6m15.836s
sys0m3.600s

Version nigtly build 3.5.20160208
real1m29.047s
user1m24.232s
sys0m3.040s

Thank you
Bartosz

2016-02-09 20:51 GMT+01:00 Brad King :

> On 02/09/2016 02:39 PM, Alan W. Irwin wrote:
> > So what branch should we follow if we want to test the on-going 3.5.x
> > effort?
> >
> > I assumed it would be "release"
>
> Yes.  I just merged several of the fixes there this morning.
>
> > but one of the key fixes to 3.5.0-rc1 is the efficiency one
> [snip]
> > Are those changes being "cooked" a bit longer or are they already in
> > the release branch under some different title?
>
> They are cooking in 'master' for few days.  This will give Bartosz
> (who reported the performance problem) some time to confirm the fixes
> work.
>
> The fixes are also available in the nightly binaries since those
> are built from 'next'.
>
> -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] FindProtobuf: prevent redundant PROTOBUF_LIBRARIES

2016-02-10 Thread Antonio Perez Barrero
Before this change, the variable PROTOBUF_LIBRARIES might get redundant
value for debug and optimized configurations, e.g.
'optimized;/usr/lib/libprotobuf.so;debug;/usr/lib/libprotobuf.so'
---
 Modules/FindProtobuf.cmake | 18 ++
 1 file changed, 6 insertions(+), 12 deletions(-)

diff --git a/Modules/FindProtobuf.cmake b/Modules/FindProtobuf.cmake
index 2f13b09..57c6e62 100644
--- a/Modules/FindProtobuf.cmake
+++ b/Modules/FindProtobuf.cmake
@@ -213,6 +213,8 @@ endif()
 # Internal function: search for normal library as well as a debug one
 #if the debug one is specified also include debug/optimized keywords
 #in *_LIBRARIES variable
+include(SelectLibraryConfigurations)
+
 function(_protobuf_find_libraries name filename)
find_library(${name}_LIBRARY
NAMES ${filename}
@@ -224,18 +226,10 @@ function(_protobuf_find_libraries name filename)
PATHS ${PROTOBUF_SRC_ROOT_FOLDER}/vsprojects/${_PROTOBUF_ARCH_DIR}Debug)
mark_as_advanced(${name}_LIBRARY_DEBUG)
 
-   if(NOT ${name}_LIBRARY_DEBUG)
-  # There is no debug library
-  set(${name}_LIBRARY_DEBUG ${${name}_LIBRARY} PARENT_SCOPE)
-  set(${name}_LIBRARIES ${${name}_LIBRARY} PARENT_SCOPE)
-   else()
-  # There IS a debug library
-  set(${name}_LIBRARIES
-  optimized ${${name}_LIBRARY}
-  debug ${${name}_LIBRARY_DEBUG}
-  PARENT_SCOPE
-  )
-   endif()
+   select_library_configurations(${name})
+   set(${name}_LIBRARY_DEBUG ${${name}_LIBRARY_DEBUG} PARENT_SCOPE)
+   set(${name}_LIBRARY ${${name}_LIBRARY} PARENT_SCOPE)
+   set(${name}_LIBRARIES ${${name}_LIBRARIES} PARENT_SCOPE)
 endfunction()
 
 # Internal function: find threads library
-- 
1.9.1

-- 

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] FindProtobuf: fix wrong library list for Unix

2016-02-10 Thread Antonio Pérez Barrero
El mar., 9 feb. 2016 a las 11:13, Rolf Eike Beer ()
escribió:

> Am 09.02.2016 11:10, schrieb Antonio Pérez Barrero:
> >>
> >> On 02/08/2016 04:24 PM, Antonio Pérez Barrero wrote:
> >> > Yes, it is possible, but currently it's not looking for the debug
> >> > library with a different name, just in a different path that is
> >> > unlikely to exist in a Unix system.
> >>
> >> The fact that a separate find_library is called for it and the result
> >> is stored in a separate (user-settable) cache entry means that it is
> >> possible to get two different values.  This convention is well
> >> established
> >> in several find modules.
> >>
> >> > Having the PROTOBUF_LIBRARIES variable getting the afore mentioned
> >> > value messes up the client code using `find_package(Protobuf)` on
> Unix.
> >>
> >> The only supported use for PROTOBUF_LIBRARIES is to pass it to
> >> target_link_libraries, and that interprets the 'optimized' and 'debug'
> >> keywords.  This is shown in the module documentation example:
> >>
> >> target_link_libraries(bar ${PROTOBUF_LIBRARIES})
> >>
> >> The documentation makes no other guarantees about the variable value.
> >>
> >
> > Thanks for your explanantion, that makes sense. I had issues because I
> > was
> > appending the value of PROTOBUF_LIBRARIES to a list and then removing
> > duplicates before calling `target_link_libraries(bar ${LIST})`. So when
> > the
> > PROTOBUF_LIBRARIES values was
> > `optimized;/usr/lib/libprotobuf.so;debug;/usr/lib/libprotobuf.so` I was
> > missing the link flag for /usr/lib/libprotobuf.so in Debug builds.
> > Skipping
> > the duplicates removal step solves my issue.
> >
> > Anyway, the root cause is the `find_library` is finding the same
> > library
> > for optimized and debug configuration. So, would a patch like this be
> > benefial?
> >
> > diff --git a/Modules/FindProtobuf.cmake b/Modules/FindProtobuf.cmake
> > index 2f13b09..35929a4 100644
> > --- a/Modules/FindProtobuf.cmake
> > +++ b/Modules/FindProtobuf.cmake
> > @@ -224,7 +224,7 @@ function(_protobuf_find_libraries name filename)
> > PATHS
> > ${PROTOBUF_SRC_ROOT_FOLDER}/vsprojects/${_PROTOBUF_ARCH_DIR}Debug)
> > mark_as_advanced(${name}_LIBRARY_DEBUG)
> >
> > -   if(NOT ${name}_LIBRARY_DEBUG)
> > +   if((NOT ${name}_LIBRARY_DEBUG) OR (${name}_LIBRARY STREQUAL
> > ${name}_LIBRARY_DEBUG))
> ># There is no debug library
> >set(${name}_LIBRARY_DEBUG ${${name}_LIBRARY} PARENT_SCOPE)
> >set(${name}_LIBRARIES ${${name}_LIBRARY} PARENT_SCOPE)
>
> Just use SelectLibraryConfigurations, that does the same automatically
> if they are identical, and also handles the cases where only debug, but
> not release is found.
>

Thanks, I tried that and got it working. I'll submit another patch as the
change covers a related but different issue.

Regards,
Antonio



> Greetings,
>
> Eike
> --
>
> 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
-- 

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] [CMake 0015964]: Borland Makefile generation Script

2016-02-10 Thread Mantis Bug Tracker

The following issue has been SUBMITTED. 
== 
https://cmake.org/Bug/view.php?id=15964 
== 
Reported By:David We
Assigned To:
== 
Project:CMake
Issue ID:   15964
Category:   CMake
Reproducibility:always
Severity:   minor
Priority:   normal
Status: new
== 
Date Submitted: 2016-02-10 03:51 EST
Last Modified:  2016-02-10 03:51 EST
== 
Summary:Borland Makefile generation Script
Description: 
The Borland makefiles are not configured correctly.

These defines are missing after the cmake process is finished.

#define HAVE_STRTOULL 1
#define HAVE_GETADDRINFO 1
#define HAVE_NTOHLL 1



Additional Information: 
I'am using the bcc32 from RadStudio Seattle ( XE10 ).
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2016-02-10 03:51 David We   New Issue
==

-- 

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 Daemon blog

2016-02-10 Thread Tobias Hunger
Hey, I did send a MR on github:-)

But I agree, I had also hoped for more active participation.

Best Regards,
Tobias

On Wed, Feb 10, 2016 at 12:07 AM, Stephen Kelly  wrote:
> Stephen Kelly wrote:
>
>> Hi,
>>
>> I just made a blog and video about the advanced features and possibilities
>> that a daemon mode for CMake can bring:
>>
>>  https://steveire.wordpress.com/2016/01/24/cmake-daemon-for-user-tools/
>>
>
>
> The lack of response on the list to any of this is quite disappointing.
>
> --
>
> 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
-- 

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