[Cmake-commits] CMake branch, master, updated. v3.7.2-1198-g83596d4

[Kitware Robot]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  83596d4ba133014b6ed1ab993f61476634e2bfdb (commit)
  from  b8db2ed79675930421ac96256d63af515e624d38 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=83596d4ba133014b6ed1ab993f61476634e2bfdb
commit 83596d4ba133014b6ed1ab993f61476634e2bfdb
Author: Kitware Robot <kwro...@kitware.com>
AuthorDate: Fri Jan 27 00:01:05 2017 -0500
Commit: Kitware Robot <kwro...@kitware.com>
CommitDate: Fri Jan 27 00:01:05 2017 -0500

CMake Nightly Date Stamp

diff --git a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 93f128f..8290ba3 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,5 +1,5 @@
 # CMake version number components.
 set(CMake_VERSION_MAJOR 3)
 set(CMake_VERSION_MINOR 7)
-set(CMake_VERSION_PATCH 20170126)
+set(CMake_VERSION_PATCH 20170127)
 #set(CMake_VERSION_RC 1)

---

Summary of changes:
 Source/CMakeVersion.cmake |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

Re: [CMake] Forcing linking compatability to old libc / libstdc++ (Linux)

[Bo Zhou]

My personal experience is,  always create the distribution on old Linux
with older compiler to keep the maximal compatibility.

Since usually the GCC will pick libstdc++ from system, so if user runs the
distribution on even older Linux, 100% sure the error raises. On
CentOS/Redhat we do have the devtool-set, but still, the older Linux + GCC
are the safest solution.

Or you can use the static link of libstdc++, but the size of binary will be
larger, and sometimes the problem still exists, and causes more problems.

On Fri, Jan 27, 2017 at 9:34 AM, Florent Castelli <
florent.caste...@gmail.com> wrote:

> I've had to deal with this in the past.
>
> For glibc, it's more tricky since when you compile on a newer
> distribution, it will automatically use the newer version of some symbols.
> Some functions have had breaking changes and to keep compatibility, they
> kept all the different version in the binary.
> But you can force the compiler to use a specific version of head but
> putting that information in a header that contains the definition for all
> those functions.
> There is a script describe in this blog post (
> https://blogs.gnome.org/tvb/2013/12/14/application-bundles-revisited/ )
> you could use to generate a compatibility header for any target version of
> glibc.
> Then, you can use a force include (-include) in your favorite build system
> (CMake) to have those used everywhere automatically.
> If your application doesn't use any external libraries linked statically
> and built against your current glibc, it should work. Otherwise, you will
> probably have to rebuild them.
>
> For libstdc++, you could potentially statically link it, it's usually fine.
> But after what I said about glibc, it means you may have to rebuild it
> using the compatibility header described before. That may be tricky too...
>
> /Florent
>
>
> On 26/01/2017 23:34, Michael Ellery wrote:
>
>> On Jan 26, 2017, at 1:45 PM, Gonzalo Garramuño 
>>> wrote:
>>>
>>>
>>>
>>> El 26/01/2017 a las 18:35, Michael Ellery escribió:
>>>
 In what way is the stdlib incompatible? Does it have bugs, or is this
 more a matter of cpp standard support?

>>> I should have been more clear.  Sorry.   The incompatabilities happen at
>>> linker time, with complaints such as:
>>>
>>> exrstdattr: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found
>>> (required by exrstdattr )
>>> exrstdattr: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found
>>> (required by /usr/local/mrViewer/lib/libIlmImf-2_2.so.22 )
>>>
>>> If I copy the latest libstdc++.so.6 I have on Ubuntu, I get:
>>>
>>> exrstdattr: /lib64/libc.so.6: version `GLIBC_2.18' not found (required
>>> by /usr/local/mrViewer/lib/libstdc++.so.6 )
>>>
>>> --
>>> Gonzalo Garramuño
>>>
>>> oh, yeah - I wasn’t paying close attention to the fact that you are
>> distributing *binaries* — to a different distro no less. This is why
>> projects often either tell users to build from source or they create
>> packages (rpms, dpkgs, etc.) on the specific distros and versions.
>>
>> That said, if you want to distribute binaries to a different distro, I
>> guess you can try static linking OR what you suggested, shipping the stdlib
>> — see:
>>
>> http://stackoverflow.com/questions/13636513/linking-libstdc-
>> statically-any-gotchas#14082540
>>
>> I personally would not want to ship a stdlib myself, but using CMake’s
>> RPATH support, you can probably make it work.
>>
>> -Mike
>>
>>
> --
>
> 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/opensou
> rce/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake
>
-- 

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

Re: [CMake] Forcing linking compatability to old libc / libstdc++ (Linux)

[Florent Castelli]

I've had to deal with this in the past.

For glibc, it's more tricky since when you compile on a newer 
distribution, it will automatically use the newer version of some 
symbols. Some functions have had breaking changes and to keep 
compatibility, they kept all the different version in the binary.
But you can force the compiler to use a specific version of head but 
putting that information in a header that contains the definition for 
all those functions.
There is a script describe in this blog post ( 
https://blogs.gnome.org/tvb/2013/12/14/application-bundles-revisited/ ) 
you could use to generate a compatibility header for any target version 
of glibc.
Then, you can use a force include (-include) in your favorite build 
system (CMake) to have those used everywhere automatically.
If your application doesn't use any external libraries linked statically 
and built against your current glibc, it should work. Otherwise, you 
will probably have to rebuild them.


For libstdc++, you could potentially statically link it, it's usually fine.
But after what I said about glibc, it means you may have to rebuild it 
using the compatibility header described before. That may be tricky too...


/Florent

On 26/01/2017 23:34, Michael Ellery wrote:

On Jan 26, 2017, at 1:45 PM, Gonzalo Garramuño  wrote:



El 26/01/2017 a las 18:35, Michael Ellery escribió:

In what way is the stdlib incompatible? Does it have bugs, or is this more a 
matter of cpp standard support?

I should have been more clear.  Sorry.   The incompatabilities happen at linker 
time, with complaints such as:

exrstdattr: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required 
by exrstdattr )
exrstdattr: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found (required 
by /usr/local/mrViewer/lib/libIlmImf-2_2.so.22 )

If I copy the latest libstdc++.so.6 I have on Ubuntu, I get:

exrstdattr: /lib64/libc.so.6: version `GLIBC_2.18' not found (required by 
/usr/local/mrViewer/lib/libstdc++.so.6 )

--
Gonzalo Garramuño


oh, yeah - I wasn’t paying close attention to the fact that you are 
distributing *binaries* — to a different distro no less. This is why projects 
often either tell users to build from source or they create packages (rpms, 
dpkgs, etc.) on the specific distros and versions.

That said, if you want to distribute binaries to a different distro, I guess 
you can try static linking OR what you suggested, shipping the stdlib — see:

http://stackoverflow.com/questions/13636513/linking-libstdc-statically-any-gotchas#14082540

I personally would not want to ship a stdlib myself, but using CMake’s RPATH 
support, you can probably make it work.

-Mike



--

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

Re: [CMake] Forcing linking compatability to old libc / libstdc++ (Linux)

[Michael Ellery]

> On Jan 26, 2017, at 1:45 PM, Gonzalo Garramuño  wrote:
> 
> 
> 
> El 26/01/2017 a las 18:35, Michael Ellery escribió:
>> In what way is the stdlib incompatible? Does it have bugs, or is this more a 
>> matter of cpp standard support?
> I should have been more clear.  Sorry.   The incompatabilities happen at 
> linker time, with complaints such as:
> 
> exrstdattr: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found 
> (required by exrstdattr )
> exrstdattr: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found 
> (required by /usr/local/mrViewer/lib/libIlmImf-2_2.so.22 )
> 
> If I copy the latest libstdc++.so.6 I have on Ubuntu, I get:
> 
> exrstdattr: /lib64/libc.so.6: version `GLIBC_2.18' not found (required by 
> /usr/local/mrViewer/lib/libstdc++.so.6 )
> 
> -- 
> Gonzalo Garramuño
> 

oh, yeah - I wasn’t paying close attention to the fact that you are 
distributing *binaries* — to a different distro no less. This is why projects 
often either tell users to build from source or they create packages (rpms, 
dpkgs, etc.) on the specific distros and versions. 

That said, if you want to distribute binaries to a different distro, I guess 
you can try static linking OR what you suggested, shipping the stdlib — see:

http://stackoverflow.com/questions/13636513/linking-libstdc-statically-any-gotchas#14082540

I personally would not want to ship a stdlib myself, but using CMake’s RPATH 
support, you can probably make it work.

-Mike

-- 

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

Re: [CMake] Forcing linking compatability to old libc / libstdc++ (Linux)

[Gonzalo Garramuño]

El 26/01/2017 a las 18:35, Michael Ellery escribió:

In what way is the stdlib incompatible? Does it have bugs, or is this more a 
matter of cpp standard support?
I should have been more clear.  Sorry.   The incompatabilities happen at 
linker time, with complaints such as:


exrstdattr: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found 
(required by exrstdattr )
exrstdattr: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.20' not found 
(required by /usr/local/mrViewer/lib/libIlmImf-2_2.so.22 )


If I copy the latest libstdc++.so.6 I have on Ubuntu, I get:

exrstdattr: /lib64/libc.so.6: version `GLIBC_2.18' not found (required 
by /usr/local/mrViewer/lib/libstdc++.so.6 )


--
Gonzalo Garramuño

--

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

Re: [CMake] Forcing linking compatability to old libc / libstdc++ (Linux)

[Michael Ellery]

> On Jan 26, 2017, at 1:23 PM, Gonzalo Garramuño  wrote:
> 
> I currently own an Ubuntu Xenial 14.04.1 LTS box in which I do all my work.   
>  I distribute a binary image viewer.   However, recently one of my users 
> tried to run the viewer on a CentOS 7 distro and found out that that distro 
> libc and libstdc++ are older and incompatible.
> 
> I would like to compile my program targeting the older libc and libstdc++.  
> Those files come with symbol version and visibility. Is there an easy way to 
> do that other than copying the old libraries?
> 
> Any help or hint is appreciated.
> 

In what way is the stdlib incompatible? Does it have bugs, or is this more a 
matter of cpp standard support? If you want to enforce/require a certain 
standard of cpp, for instance, have a look at:

https://cmake.org/cmake/help/v3.1/variable/CMAKE_CXX_STANDARD_REQUIRED.html

If you want to enforce certain language features, you can consider specifying 
compile-features:

https://cmake.org/cmake/help/v3.1/manual/cmake-compile-features.7.html
https://cmake.org/cmake/help/v3.1/prop_gbl/CMAKE_CXX_KNOWN_FEATURES.html#prop_gbl:CMAKE_CXX_KNOWN_FEATURES

Now, that might still not solve the immediate problem of an old toolchain on 
Centos7, but at least CMake will make clear to the user what’s missing.  For 
Centos/Redhat specifically, I’ve had good luck with devtoolset for 
installing/using an updated toolchain:

https://www.softwarecollections.org/en/scls/rhscl/devtoolset-3

HTH,
Mike Ellery



-- 

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

[CMake] Forcing linking compatability to old libc / libstdc++ (Linux)

[Gonzalo Garramuño]

I currently own an Ubuntu Xenial 14.04.1 LTS box in which I do all my 
work.I distribute a binary image viewer.   However, recently one of 
my users tried to run the viewer on a CentOS 7 distro and found out that 
that distro libc and libstdc++ are older and incompatible.


I would like to compile my program targeting the older libc and 
libstdc++.  Those files come with symbol version and visibility. Is 
there an easy way to do that other than copying the old libraries?


Any help or hint is appreciated.

--
Gonzalo Garramuño

--

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

Re: [cmake-developers] What should the behaviour of NUMBER_OF_LOGICAL_CORES be?

[Daniel Pfeifer]

Hi,

I agree that it should be total number of cores. In addition,
cmake_host_system_information() might be extended to provide the number of
cores per physical core.
This aligns with the information in the XML procuded by CTest: The Site
element has the attributes NumberOfLogicalCPU, NumberOfPhysicalCPU, and
LogicalProcessorsPerPhysical.

Cheers, Daniel

On Thu, Jan 26, 2017 at 9:56 PM, Nicolás Bértolo 
wrote:

> Hi,
>
> This question comes from https://gitlab.kitware.com/
> cmake/cmake/issues/16594
> Currently cmake_host_system_information(RESULT logical QUERY
> NUMBER_OF_LOGICAL_CORES) is buggy, some parts of the code that implement it
> assume it refers to the number of cores in the system and some assume it is
> the number of cores per physical core. The documentation implies it is the
> total number of cores, but in my system (AMD FX-8320) it is equal to 1 when
> it should be 8.
>
> I have offered myself to fix this bug, but first I would like to know what
> is the correct return value of this call should be.
> Should it return the number of cores per physical core or the total number
> of cores in the system?
>
> I think it should be the latter, but I would like to hear your opinions.
>
> Regards,
> Nicolás.
>
>
>
> --
> [image: Avast logo]
> 
>
> El software de antivirus Avast ha analizado este correo electrónico en
> busca de virus.
> www.avast.com
> 
>
>
> --
>
> 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] What should the behaviour of NUMBER_OF_LOGICAL_CORES be?

[Nicolás Bértolo]

Hi,

This question comes from https://gitlab.kitware.com/cmake/cmake/issues/16594
Currently cmake_host_system_information(RESULT logical QUERY 
NUMBER_OF_LOGICAL_CORES) is buggy, some parts of the code that implement 
it assume it refers to the number of cores in the system and some assume 
it is the number of cores per physical core. The documentation implies 
it is the total number of cores, but in my system (AMD FX-8320) it is 
equal to 1 when it should be 8.


I have offered myself to fix this bug, but first I would like to know 
what is the correct return value of this call should be.
Should it return the number of cores per physical core or the total 
number of cores in the system?


I think it should be the latter, but I would like to hear your opinions.

Regards,
Nicolás.

||



---
El software de antivirus Avast ha analizado este correo electrónico en busca de 
virus.
https://www.avast.com/antivirus
-- 

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-commits] CMake branch, next, updated. v3.7.2-2371-g0758c65

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  0758c659996640f6558d09ee9835ad325c60c25d (commit)
   via  266fe3bd760dcd93d51c556baff7dfcf5bfc66f4 (commit)
   via  d525754eabef7a9f6e6696ae323a8ed965e12f2e (commit)
   via  45405f00d27031fb9641408c56673532a3ee3bde (commit)
   via  50e1c1056ea82690474dc186d7a4103b33547fa6 (commit)
   via  8643ca75c705568bc9bb084a5182baef04865d2d (commit)
  from  4b9e085f77ac2500d2a3bbd2253acbc6b1c84c0e (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0758c659996640f6558d09ee9835ad325c60c25d
commit 0758c659996640f6558d09ee9835ad325c60c25d
Merge: 4b9e085 266fe3b
Author: Brad King 
AuthorDate: Thu Jan 26 13:36:45 2017 -0500
Commit: CMake Topic Stage 
CommitDate: Thu Jan 26 13:36:45 2017 -0500

Merge topic '16432-static-frameworks' into next

266fe3bd Apple: Add support for static frameworks
d525754e Xcode: Refactor RunCMake.Framework test to prepare for static 
frameworks
45405f00 Xcode: Ignore Xcode project warning until issue is fixed
50e1c105 Makefile: For static libraries remove only the "real" lib before 
creating
8643ca75 Makefile: Re-order list of files to clean


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=266fe3bd760dcd93d51c556baff7dfcf5bfc66f4
commit 266fe3bd760dcd93d51c556baff7dfcf5bfc66f4
Author: Gregor Jasny 
AuthorDate: Mon Dec 26 18:07:24 2016 +0100
Commit: Brad King 
CommitDate: Thu Jan 26 13:35:14 2017 -0500

Apple: Add support for static frameworks

Closes: #16432

diff --git a/Help/command/add_library.rst b/Help/command/add_library.rst
index 36adcbe..af75a39 100644
--- a/Help/command/add_library.rst
+++ b/Help/command/add_library.rst
@@ -33,7 +33,7 @@ type is ``STATIC`` or ``SHARED`` based on whether the current 
value of the
 variable :variable:`BUILD_SHARED_LIBS` is ``ON``.  For ``SHARED`` and
 ``MODULE`` libraries the :prop_tgt:`POSITION_INDEPENDENT_CODE` target
 property is set to ``ON`` automatically.
-A ``SHARED`` library may be marked with the :prop_tgt:`FRAMEWORK`
+A ``SHARED`` or ``STATIC`` library may be marked with the :prop_tgt:`FRAMEWORK`
 target property to create an OS X Framework.
 
 If a library does not export any symbols, it must not be declared as a
diff --git a/Help/command/install.rst b/Help/command/install.rst
index d57dd75..70087a4 100644
--- a/Help/command/install.rst
+++ b/Help/command/install.rst
@@ -90,8 +90,10 @@ project.  There are five kinds of target files that may be 
installed:
 ``ARCHIVE``, ``LIBRARY``, ``RUNTIME``, ``FRAMEWORK``, and ``BUNDLE``.
 Executables are treated as ``RUNTIME`` targets, except that those
 marked with the ``MACOSX_BUNDLE`` property are treated as ``BUNDLE``
-targets on OS X.  Static libraries are always treated as ``ARCHIVE``
-targets.  Module libraries are always treated as ``LIBRARY`` targets.
+targets on OS X.  Static libraries are treated as ``ARCHIVE`` targets,
+except that those marked with the ``FRAMEWORK`` property are treated
+as ``FRAMEWORK`` targets on OS X.
+Module libraries are always treated as ``LIBRARY`` targets.
 For non-DLL platforms shared libraries are treated as ``LIBRARY``
 targets, except that those marked with the ``FRAMEWORK`` property are
 treated as ``FRAMEWORK`` targets on OS X.  For DLL platforms the DLL
diff --git a/Help/prop_tgt/FRAMEWORK.rst b/Help/prop_tgt/FRAMEWORK.rst
index 8120c36..495d30e 100644
--- a/Help/prop_tgt/FRAMEWORK.rst
+++ b/Help/prop_tgt/FRAMEWORK.rst
@@ -1,9 +1,9 @@
 FRAMEWORK
 -
 
-Build ``SHARED`` library as Framework Bundle on the OS X and iOS.
+Build ``SHARED`` or ``STATIC`` library as Framework Bundle on the OS X and iOS.
 
-If a ``SHARED`` library target has this property set to ``TRUE`` it will be
+If such a library target has this property set to ``TRUE`` it will be
 built as a framework when built on the OS X and iOS.  It will have the
 directory structure required for a framework and will be suitable to
 be used with the ``-framework`` option
diff --git a/Help/release/dev/static-frameworks.rst 
b/Help/release/dev/static-frameworks.rst
new file mode 100644
index 000..eae80bd
--- /dev/null
+++ b/Help/release/dev/static-frameworks.rst
@@ -0,0 +1,6 @@
+static-frameworks
+-
+
+* The :prop_tgt:`FRAMEWORK` property could now also be applied to
+  static libraries on Apple targets.  It will result in a proper
+  Framework but with a static library inside.
diff --git a/Source/cmGeneratorTarget.cxx b/Source/cmGeneratorTarget.cxx
index dcf3764..6ce8140 

[Cmake-commits] CMake branch, next, updated. v3.7.2-2365-g4b9e085

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  4b9e085f77ac2500d2a3bbd2253acbc6b1c84c0e (commit)
   via  c3a22518f83dfe8e1787e93f05398a5263cc781a (commit)
   via  d491172445dcd32547fbeb3598510455e8e44132 (commit)
   via  1a2a9b0d08c7ba2af168856b1220d42ff9a80921 (commit)
  from  7c51e930146249c1220275a030af5b557b0a4799 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4b9e085f77ac2500d2a3bbd2253acbc6b1c84c0e
commit 4b9e085f77ac2500d2a3bbd2253acbc6b1c84c0e
Merge: 7c51e93 c3a2251
Author: Brad King 
AuthorDate: Thu Jan 26 13:05:12 2017 -0500
Commit: CMake Topic Stage 
CommitDate: Thu Jan 26 13:05:12 2017 -0500

Merge topic 'test-GeneratorExpression-update' into next

c3a22518 Tests: Extend GeneratorExpression to work with more configurations
d4911724 Tests: Teach GeneratorExpression to cover spaces in include dirs
1a2a9b0d Tests: Simplify GeneratorExpression imported include directory 
check


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c3a22518f83dfe8e1787e93f05398a5263cc781a
commit c3a22518f83dfe8e1787e93f05398a5263cc781a
Author: Brad King 
AuthorDate: Thu Jan 26 10:13:14 2017 -0500
Commit: Brad King 
CommitDate: Thu Jan 26 10:16:08 2017 -0500

Tests: Extend GeneratorExpression to work with more configurations

Add missing pieces for RelWithDebInfo and MinSizeRel.

diff --git a/Tests/GeneratorExpression/CMakeLists.txt 
b/Tests/GeneratorExpression/CMakeLists.txt
index dd86b6f..3091780 100644
--- a/Tests/GeneratorExpression/CMakeLists.txt
+++ b/Tests/GeneratorExpression/CMakeLists.txt
@@ -161,6 +161,10 @@ set_property(TARGET imported3 APPEND PROPERTY
   INTERFACE_INCLUDE_DIRECTORIES 
$<$:$>)
 set_property(TARGET imported3 APPEND PROPERTY
   INTERFACE_INCLUDE_DIRECTORIES 
$<$:$>)
+set_property(TARGET imported3 APPEND PROPERTY
+  INTERFACE_INCLUDE_DIRECTORIES 
$<$:$>)
+set_property(TARGET imported3 APPEND PROPERTY
+  INTERFACE_INCLUDE_DIRECTORIES 
$<$:$>)
 
 add_library(imported4 SHARED IMPORTED)
 set_property(TARGET imported4 APPEND PROPERTY
diff --git a/Tests/GeneratorExpression/check-part3.cmake 
b/Tests/GeneratorExpression/check-part3.cmake
index 57abbcc..9014406 100644
--- a/Tests/GeneratorExpression/check-part3.cmake
+++ b/Tests/GeneratorExpression/check-part3.cmake
@@ -13,7 +13,7 @@ if(config AND NOT config STREQUAL NoConfig)
 message(SEND_ERROR "test_imported_includes is not correct: 
${test_imported_includes}")
   endif()
 else()
-  if(NOT "${test_imported_includes}" MATCHES "^;$")
+  if(NOT "${test_imported_includes}" MATCHES "^;;;$")
 message(SEND_ERROR "test_imported_includes is not an empty list: 
${test_imported_includes}")
   endif()
 endif()

https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d491172445dcd32547fbeb3598510455e8e44132
commit d491172445dcd32547fbeb3598510455e8e44132
Author: Brad King 
AuthorDate: Thu Jan 26 10:11:25 2017 -0500
Commit: Brad King 
CommitDate: Thu Jan 26 10:11:25 2017 -0500

Tests: Teach GeneratorExpression to cover spaces in include dirs

Add a space to the imported include directories used for the test.
This works around funny quoted-`;` interpretation by Visual Studio.

diff --git a/Tests/GeneratorExpression/CMakeLists.txt 
b/Tests/GeneratorExpression/CMakeLists.txt
index 8ecfdd9..dd86b6f 100644
--- a/Tests/GeneratorExpression/CMakeLists.txt
+++ b/Tests/GeneratorExpression/CMakeLists.txt
@@ -145,13 +145,13 @@ add_library(imported1 SHARED IMPORTED)
 set_property(TARGET imported1 PROPERTY IMPORTED_LOCATION_RELEASE release_loc)
 set_property(TARGET imported1 PROPERTY IMPORTED_LOCATION_DEBUG debug_loc)
 set_property(TARGET imported1 PROPERTY IMPORTED_CONFIGURATIONS RELEASE DEBUG)
-set_property(TARGET imported1 PROPERTY INTERFACE_INCLUDE_DIRECTORIES 
/imported1/include)
+set_property(TARGET imported1 PROPERTY INTERFACE_INCLUDE_DIRECTORIES 
"/imported1/include/with space")
 
 add_library(imported2 SHARED IMPORTED)
 set_property(TARGET imported2 PROPERTY IMPORTED_LOCATION_RELEASE release_loc)
 set_property(TARGET imported2 PROPERTY IMPORTED_LOCATION_DEBUG debug_loc)
 set_property(TARGET imported2 PROPERTY IMPORTED_CONFIGURATIONS RELEASE DEBUG)
-set_property(TARGET imported2 PROPERTY INTERFACE_INCLUDE_DIRECTORIES 

Re: [cmake-developers] Eclipse CDT Managed build

[Ben Boeckel]

On Thu, Jan 26, 2017 at 11:41:21 -0500, Paul Smith wrote:
> IMO the right place for managing relocatable builds is in the
> compiler/linker, not in the build tool.

This is about making the files CMake writes relocatable, not the
resulting binaries.

--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] Eclipse CDT Managed build

[Paul Smith]

IMO the right place for managing relocatable builds is in the
compiler/linker, not in the build tool.

The compiler/linker should provide options that allow the output to be
relocatable regardless of the contents of the command line.  GCC for
example has -fdebug-prefix-map that will allow you to remove prefixes
from pathnames in debug sections of the output.  Unfortunately this is
only part of the solution since it doesn't help with __FILE__ (for
example).  Nevertheless this is the right direction, rather than
modifying the build system.


On Thu, 2017-01-26 at 14:01 +, Bøe, Sebastian wrote:
> Thank you for the warning and support. We would prefer to not
> maintain
> a fork, but I have not been able to find any other technology
> that is suitable.
> 
> For future reference. The intended use-case is for CMake to act 
> as an engine in an IDE project generator solution similar to the
> below
> solutions[0].
> 
> [0] 
> http://start.atmel.com/
> http://www.st.com/en/embedded-software/stm32cube-embedded-software.ht
> ml
> 
> 
> 
> -Original Message-
> From: Brad King [mailto:brad.k...@kitware.com] 
> Sent: 26. januar 2017 14:18
> To: Bøe, Sebastian 
> Cc: ben.boec...@kitware.com; cmake-developers@cmake.org
> Subject: Re: [cmake-developers] Eclipse CDT Managed build
> 
> On 01/26/2017 05:57 AM, Bøe, Sebastian wrote:
> > 
> > I will investigate relocatable builds, because in spite of this
> > not 
> > being trivial, I think CMake still comes out as the best suited
> > technology for my use-case.
> 
> We once had an option to produce relative paths in the build system
> and it was a never ending mess of bugs.  Eventually it was ripped
> out.
> It is unlikely we will accept changes to try to re-introduce such an
> option.
> 
> -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-commits] CMake branch, next, updated. v3.7.2-2361-g7c51e93

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  7c51e930146249c1220275a030af5b557b0a4799 (commit)
   via  895f7f16a79428689a263ba5cd9a72647dc8e912 (commit)
  from  63bba4d2b9d729ffb852e93df4b04c6635f04c21 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7c51e930146249c1220275a030af5b557b0a4799
commit 7c51e930146249c1220275a030af5b557b0a4799
Merge: 63bba4d 895f7f1
Author: Brad King 
AuthorDate: Thu Jan 26 11:19:16 2017 -0500
Commit: CMake Topic Stage 
CommitDate: Thu Jan 26 11:19:16 2017 -0500

Merge topic 'genex-if' into next

895f7f16 Genex: Add `IF` generator expression


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=895f7f16a79428689a263ba5cd9a72647dc8e912
commit 895f7f16a79428689a263ba5cd9a72647dc8e912
Author: Colby Pike 
AuthorDate: Mon Jan 23 20:14:03 2017 -0700
Commit: Brad King 
CommitDate: Thu Jan 26 11:18:50 2017 -0500

Genex: Add `IF` generator expression

This allows a single condition to be used to choose between two
alternatives.  Without this the condition must be duplicated with
one surrounded by `NOT`.

Closes: #15585

diff --git a/Help/manual/cmake-generator-expressions.7.rst 
b/Help/manual/cmake-generator-expressions.7.rst
index 64d15a9..3a225ad 100644
--- a/Help/manual/cmake-generator-expressions.7.rst
+++ b/Help/manual/cmake-generator-expressions.7.rst
@@ -51,6 +51,8 @@ Available logical expressions are:
   ``0`` if all ``?`` are ``0``, else ``1``
 ``$``
   ``0`` if ``?`` is ``1``, else ``1``
+``$```
+  ``true-value...`` if ``?`` is ``1``, ``false-value...`` if ``?`` is ``0``
 ``$``
   ``1`` if ``a`` is STREQUAL ``b``, else ``0``
 ``$``
diff --git a/Help/release/dev/if-genex.rst b/Help/release/dev/if-genex.rst
new file mode 100644
index 000..62be3a7
--- /dev/null
+++ b/Help/release/dev/if-genex.rst
@@ -0,0 +1,7 @@
+genex-if
+
+
+* A new logical generator expression for immediate-if was added:
+  ``$``. It takes three arguments: One
+  condition, a true-value, and a false-value. Resolves to the true-value if the
+  condition is ``1``, and resolves to the false-value if the condition is 
``0``.
diff --git a/Source/cmGeneratorExpressionNode.cxx 
b/Source/cmGeneratorExpressionNode.cxx
index 398f95b..66202df 100644
--- a/Source/cmGeneratorExpressionNode.cxx
+++ b/Source/cmGeneratorExpressionNode.cxx
@@ -162,6 +162,27 @@ static const struct BoolNode : public 
cmGeneratorExpressionNode
   }
 } boolNode;
 
+static const struct IfNode : public cmGeneratorExpressionNode
+{
+  IfNode() {}
+
+  int NumExpectedParameters() const CM_OVERRIDE { return 3; }
+
+  std::string Evaluate(const std::vector& parameters,
+   cmGeneratorExpressionContext* context,
+   const GeneratorExpressionContent* content,
+   cmGeneratorExpressionDAGChecker*) const CM_OVERRIDE
+  {
+if (parameters[0] != "1" && parameters[0] != "0") {
+  reportError(context, content->GetOriginalExpression(),
+  "First parameter to $ must resolve to exactly one '0' "
+  "or '1' value.");
+  return std::string();
+}
+return parameters[0] == "1" ? parameters[1] : parameters[2];
+  }
+} ifNode;
+
 static const struct StrEqualNode : public cmGeneratorExpressionNode
 {
   StrEqualNode() {}
@@ -1757,6 +1778,7 @@ const cmGeneratorExpressionNode* 
cmGeneratorExpressionNode::GetNode(
 nodeMap["UPPER_CASE"] = 
 nodeMap["MAKE_C_IDENTIFIER"] = 
 nodeMap["BOOL"] = 
+nodeMap["IF"] = 
 nodeMap["ANGLE-R"] = _rNode;
 nodeMap["COMMA"] = 
 nodeMap["SEMICOLON"] = 
diff --git a/Tests/GeneratorExpression/CMakeLists.txt 
b/Tests/GeneratorExpression/CMakeLists.txt
index f0d6abf..f920188 100644
--- a/Tests/GeneratorExpression/CMakeLists.txt
+++ b/Tests/GeneratorExpression/CMakeLists.txt
@@ -246,6 +246,10 @@ add_custom_target(check-part4 ALL
 # CMake as command-line argument
 -Dtest_shell_path=${path_prefix}$
 -Dpath_prefix=${path_prefix}
+-Dif_1=$
+-Dif_2=$
+-Dif_3=$,a,b>
+-Dif_4=$,a,b>
 -DWIN32=${WIN32}
 -DCMAKE_GENERATOR=${CMAKE_GENERATOR}
 -P ${CMAKE_CURRENT_SOURCE_DIR}/check-part4.cmake
diff --git a/Tests/GeneratorExpression/check-part4.cmake 
b/Tests/GeneratorExpression/check-part4.cmake
index 9e516d5..f5d14dd 100644
--- 

Re: [CMake] externalproject_add and generating sources

[Michael Ellery]

> On Jan 26, 2017, at 1:23 AM, David Jobet  wrote:
> 
> Hello,
> 
> suppose I want to use protobuf and integrate it in my project with 
> externalproject_add. (actually, I just have precompiled binaries and libs + 
> header files, I don't have the full sources)
> Once the project has been 'built' (actually, installed by a custom rpm-like 
> tool to a shared path), I can use the protoc compiler to generate protobuf 
> c++ files (.pb.h and .pb.cpp files) from a .proto description file.
> I can add_dependencies so that the external project is built before projects 
> depending on libprotobuf.a.
> 
> However, I don't know how to do the same thing with .pb.h and .pb.cpp files 
> which use a .proto file and the protoc compiler.
> 
> make is fine with it, but ninja complains with an error like this :
> ninja: error: '/path_to_external_projects/protobuf/2.6.0.4/bin/protoc', 
> needed by 'some_project/SomeFile.pb.h', missing and no known rule to make it
> 
> how can I tell ninja that protoc is going to be provided by externalproject ?
> If I use byproducts, ninja is happy, but "ninja clean" deletes 
> /path_to_external_projects/protobuf/2.6.0.4/bin/protoc.
> I don't want that to happen since 
> /path_to_external_projects/protobuf/2.6.0.4/bin/protoc is shared with other 
> users.
> 

I’ve never used protobufs as an external project (I’ve always just done a 
one-time setup/install)…but is there a reason you can’t just use the standard 
finder to locate it?  
https://github.com/Kitware/CMake/blob/master/Modules/FindProtobuf.cmake

-Mike

-- 

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

[Cmake-commits] CMake branch, next, updated. v3.7.2-2359-g63bba4d

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  63bba4d2b9d729ffb852e93df4b04c6635f04c21 (commit)
   via  24d73fa0eb2e9f7cdc8fb8192445ce3ee04cf7d3 (commit)
  from  1325cfc3a76387a327b5758adcf8ef42f2e19af3 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=63bba4d2b9d729ffb852e93df4b04c6635f04c21
commit 63bba4d2b9d729ffb852e93df4b04c6635f04c21
Merge: 1325cfc 24d73fa
Author: Brad King 
AuthorDate: Thu Jan 26 11:05:46 2017 -0500
Commit: CMake Topic Stage 
CommitDate: Thu Jan 26 11:05:46 2017 -0500

Merge topic 'GNUG_define' into next

24d73fa0 GNUC: also check __GNUG__ define when checking for g++


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=24d73fa0eb2e9f7cdc8fb8192445ce3ee04cf7d3
commit 24d73fa0eb2e9f7cdc8fb8192445ce3ee04cf7d3
Author: Rolf Eike Beer 
AuthorDate: Wed Jan 25 21:53:40 2017 +0100
Commit: Rolf Eike Beer 
CommitDate: Wed Jan 25 21:53:40 2017 +0100

GNUC: also check __GNUG__ define when checking for g++

At least the scratchbox compiler for the N900, which basically is a gcc 4.2,
sets only __GNUG__ in C++ mode, but not __GNUC__. It does indeed set
__GNUC_MINOR__ and __GNUC_PATCHLEVEL__. Extend the compiler detection code 
for
GNU compilers in C++ mode to look at __GNUG__ in case __GNUC__ is absent.

diff --git a/Modules/Compiler/GNU-DetermineCompiler.cmake 
b/Modules/Compiler/GNU-C-DetermineCompiler.cmake
similarity index 100%
copy from Modules/Compiler/GNU-DetermineCompiler.cmake
copy to Modules/Compiler/GNU-C-DetermineCompiler.cmake
diff --git a/Modules/Compiler/GNU-DetermineCompiler.cmake 
b/Modules/Compiler/GNU-CXX-DetermineCompiler.cmake
similarity index 53%
rename from Modules/Compiler/GNU-DetermineCompiler.cmake
rename to Modules/Compiler/GNU-CXX-DetermineCompiler.cmake
index 6ddc566..c25b147 100644
--- a/Modules/Compiler/GNU-DetermineCompiler.cmake
+++ b/Modules/Compiler/GNU-CXX-DetermineCompiler.cmake
@@ -1,8 +1,12 @@
 
-set(_compiler_id_pp_test "defined(__GNUC__)")
+set(_compiler_id_pp_test "defined(__GNUC__) || defined(__GNUG__)")
 
 set(_compiler_id_version_compute "
-# define @PREFIX@COMPILER_VERSION_MAJOR @MACRO_DEC@(__GNUC__)
+# if defined(__GNUC__)
+#  define @PREFIX@COMPILER_VERSION_MAJOR @MACRO_DEC@(__GNUC__)
+# else
+#  define @PREFIX@COMPILER_VERSION_MAJOR @MACRO_DEC@(__GNUG__)
+# endif
 # if defined(__GNUC_MINOR__)
 #  define @PREFIX@COMPILER_VERSION_MINOR @MACRO_DEC@(__GNUC_MINOR__)
 # endif

---

Summary of changes:
 ...U-DetermineCompiler.cmake => GNU-C-DetermineCompiler.cmake} |0
 ...DetermineCompiler.cmake => GNU-CXX-DetermineCompiler.cmake} |8 ++--
 2 files changed, 6 insertions(+), 2 deletions(-)
 copy Modules/Compiler/{GNU-DetermineCompiler.cmake => 
GNU-C-DetermineCompiler.cmake} (100%)
 rename Modules/Compiler/{GNU-DetermineCompiler.cmake => 
GNU-CXX-DetermineCompiler.cmake} (53%)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v3.7.2-2357-g1325cfc

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  1325cfc3a76387a327b5758adcf8ef42f2e19af3 (commit)
   via  b8db2ed79675930421ac96256d63af515e624d38 (commit)
   via  90ee3bd3b0b22c62cbb96334ba6620b89ea3d6be (commit)
   via  4ab35eb661f92686cc3ed3a1b52f7c2ef49bf8a1 (commit)
   via  09cad3090415fbe59474232675e8124c8332116a (commit)
   via  6ee9efa883c19c7c1ebfba660c76d42551bbaee8 (commit)
   via  a45de72cc437a13179e933509d524d2088a86002 (commit)
  from  67c2364394141cecc3aa1f3c065ff25ce71a4efe (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1325cfc3a76387a327b5758adcf8ef42f2e19af3
commit 1325cfc3a76387a327b5758adcf8ef42f2e19af3
Merge: 67c2364 b8db2ed
Author: Brad King 
AuthorDate: Thu Jan 26 10:41:04 2017 -0500
Commit: Brad King 
CommitDate: Thu Jan 26 10:41:04 2017 -0500

Merge branch 'master' into next


---

Summary of changes:
 Source/CMakeVersion.cmake |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.7.2-1193-g4ab35eb

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  4ab35eb661f92686cc3ed3a1b52f7c2ef49bf8a1 (commit)
   via  796dea67a68be432f98e2fef50059c93106557a2 (commit)
  from  09cad3090415fbe59474232675e8124c8332116a (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4ab35eb661f92686cc3ed3a1b52f7c2ef49bf8a1
commit 4ab35eb661f92686cc3ed3a1b52f7c2ef49bf8a1
Merge: 09cad30 796dea6
Author: Brad King 
AuthorDate: Thu Jan 26 10:40:42 2017 -0500
Commit: CMake Topic Stage 
CommitDate: Thu Jan 26 10:40:42 2017 -0500

Merge topic 'pkg-config-recheck'

796dea67 FindPkgConfig: Recheck pkg-config on parameter change.


---

Summary of changes:
 Help/release/dev/pkg-config-recheck.rst |7 +++
 Modules/FindPkgConfig.cmake |5 -
 2 files changed, 11 insertions(+), 1 deletion(-)
 create mode 100644 Help/release/dev/pkg-config-recheck.rst


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.7.2-1197-gb8db2ed

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  b8db2ed79675930421ac96256d63af515e624d38 (commit)
   via  ef47272b075a2ad8018481d3fdfb6f2beb514056 (commit)
  from  90ee3bd3b0b22c62cbb96334ba6620b89ea3d6be (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b8db2ed79675930421ac96256d63af515e624d38
commit b8db2ed79675930421ac96256d63af515e624d38
Merge: 90ee3bd ef47272
Author: Brad King 
AuthorDate: Thu Jan 26 10:40:47 2017 -0500
Commit: CMake Topic Stage 
CommitDate: Thu Jan 26 10:40:47 2017 -0500

Merge topic 'tests_auto_type'

ef47272b Tests: use cxx_auto_type only if actually available


---

Summary of changes:
 Tests/CMakeCommands/target_compile_features/CMakeLists.txt |2 +-
 Tests/CompileFeatures/CMakeLists.txt   |3 +++
 2 files changed, 4 insertions(+), 1 deletion(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.7.2-1191-g09cad30

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  09cad3090415fbe59474232675e8124c8332116a (commit)
   via  4bc2c16b5d01a66c00100171ad083e9ab5a6506c (commit)
   via  9702b3eefd2baccd24eea9779e17da8fc143fa4c (commit)
  from  6ee9efa883c19c7c1ebfba660c76d42551bbaee8 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=09cad3090415fbe59474232675e8124c8332116a
commit 09cad3090415fbe59474232675e8124c8332116a
Merge: 6ee9efa 4bc2c16
Author: Brad King 
AuthorDate: Thu Jan 26 10:40:39 2017 -0500
Commit: CMake Topic Stage 
CommitDate: Thu Jan 26 10:40:39 2017 -0500

Merge topic 'FindGTK2_RunTwice'

4bc2c16b FindGTK2: Add unit test to check variables when run twice
9702b3ee FindGTK2: Fix GTK2_LIBRARIES and GTK2_TARGETS when called twice


---

Summary of changes:
 Modules/FindGTK2.cmake |   82 ++--
 Tests/RunCMake/CMakeLists.txt  |5 ++
 .../{ClangTidy => FindGTK2}/CMakeLists.txt |0
 Tests/RunCMake/FindGTK2/FindGTK2RunTwice.cmake |   21 +
 Tests/RunCMake/FindGTK2/RunCMakeTest.cmake |3 +
 5 files changed, 69 insertions(+), 42 deletions(-)
 copy Tests/RunCMake/{ClangTidy => FindGTK2}/CMakeLists.txt (100%)
 create mode 100644 Tests/RunCMake/FindGTK2/FindGTK2RunTwice.cmake
 create mode 100644 Tests/RunCMake/FindGTK2/RunCMakeTest.cmake


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, master, updated. v3.7.2-1188-g6ee9efa

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, master has been updated
   via  6ee9efa883c19c7c1ebfba660c76d42551bbaee8 (commit)
   via  2759e22575b9c63f3162a9629c2d8aa6b9d7effa (commit)
  from  a45de72cc437a13179e933509d524d2088a86002 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=6ee9efa883c19c7c1ebfba660c76d42551bbaee8
commit 6ee9efa883c19c7c1ebfba660c76d42551bbaee8
Merge: a45de72 2759e22
Author: Brad King 
AuthorDate: Thu Jan 26 10:40:36 2017 -0500
Commit: CMake Topic Stage 
CommitDate: Thu Jan 26 10:40:36 2017 -0500

Merge topic 'FindLua-versioned-lib'

2759e225 FindLua: try to find library according to version from header


---

Summary of changes:
 Modules/FindLua.cmake |   16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)


hooks/post-receive
-- 
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/mailman/listinfo/cmake-commits

[Cmake-commits] CMake branch, next, updated. v3.7.2-2350-g67c2364

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  67c2364394141cecc3aa1f3c065ff25ce71a4efe (commit)
   via  243aed525a2fd8e5fe32139fd0f8d0cc0e40cc33 (commit)
  from  2a1a1cd66b63cac5cf2aff533bec4c35984a115c (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=67c2364394141cecc3aa1f3c065ff25ce71a4efe
commit 67c2364394141cecc3aa1f3c065ff25ce71a4efe
Merge: 2a1a1cd 243aed5
Author: Brad King 
AuthorDate: Thu Jan 26 10:24:03 2017 -0500
Commit: CMake Topic Stage 
CommitDate: Thu Jan 26 10:24:03 2017 -0500

Merge topic 'topic-reproducible-build' into next

243aed52 cmTimestamp: Support SOURCE_DATE_EPOCH to override current time


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=243aed525a2fd8e5fe32139fd0f8d0cc0e40cc33
commit 243aed525a2fd8e5fe32139fd0f8d0cc0e40cc33
Author: Bernhard M. Wiedemann 
AuthorDate: Wed Jan 25 07:15:40 2017 +0100
Commit: Brad King 
CommitDate: Thu Jan 26 10:21:41 2017 -0500

cmTimestamp: Support SOURCE_DATE_EPOCH to override current time

See https://reproducible-builds.org/ for why this is good and
https://reproducible-builds.org/specs/source-date-epoch/ for the
definition of this variable.

diff --git a/Help/command/string.rst b/Help/command/string.rst
index 77538f6..2c7847a 100644
--- a/Help/command/string.rst
+++ b/Help/command/string.rst
@@ -329,6 +329,12 @@ If no explicit  is given it will 
default to:
 
 Write a string which can be used as an identifier in C.
 
+.. note::
+
+  If the ``SOURCE_DATE_EPOCH`` environment variable is set,
+  its value will be used instead of the current time.
+  See https://reproducible-builds.org/specs/source-date-epoch/ for details.
+
 UUID
 
 
diff --git a/Help/release/dev/SOURCE_DATE_EPOCH.rst 
b/Help/release/dev/SOURCE_DATE_EPOCH.rst
new file mode 100644
index 000..576e1da
--- /dev/null
+++ b/Help/release/dev/SOURCE_DATE_EPOCH.rst
@@ -0,0 +1,5 @@
+SOURCE_DATE_EPOCH
+-
+
+* The :command:`string(TIMESTAMP)` will now honor the ``SOURCE_DATE_EPOCH``
+  environment variable and use its value instead of the current time.
diff --git a/Source/cmTimestamp.cxx b/Source/cmTimestamp.cxx
index 4a97114..1e5ac5b 100644
--- a/Source/cmTimestamp.cxx
+++ b/Source/cmTimestamp.cxx
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "cmSystemTools.h"
 
@@ -12,6 +13,16 @@ std::string cmTimestamp::CurrentTime(const std::string& 
formatString,
  bool utcFlag)
 {
   time_t currentTimeT = time(CM_NULLPTR);
+  std::string source_date_epoch;
+  cmSystemTools::GetEnv("SOURCE_DATE_EPOCH", source_date_epoch);
+  if (!source_date_epoch.empty()) {
+std::istringstream iss(source_date_epoch);
+iss >> currentTimeT;
+if (iss.fail() || !iss.eof()) {
+  cmSystemTools::Error("Cannot parse SOURCE_DATE_EPOCH as integer");
+  exit(27);
+}
+  }
   if (currentTimeT == time_t(-1)) {
 return std::string();
   }
diff --git a/Tests/RunCMake/string/RunCMakeTest.cmake 
b/Tests/RunCMake/string/RunCMakeTest.cmake
index 8067d9d..38a77b0 100644
--- a/Tests/RunCMake/string/RunCMakeTest.cmake
+++ b/Tests/RunCMake/string/RunCMakeTest.cmake
@@ -6,6 +6,11 @@ run_cmake(AppendNoArgs)
 run_cmake(Concat)
 run_cmake(ConcatNoArgs)
 
+run_cmake(Timestamp)
+run_cmake(TimestampEmpty)
+run_cmake(TimestampInvalid)
+run_cmake(TimestampInvalid2)
+
 run_cmake(Uuid)
 run_cmake(UuidMissingNamespace)
 run_cmake(UuidMissingNamespaceValue)
diff --git a/Tests/RunCMake/string/Timestamp-result.txt 
b/Tests/RunCMake/string/Timestamp-result.txt
new file mode 100644
index 000..573541a
--- /dev/null
+++ b/Tests/RunCMake/string/Timestamp-result.txt
@@ -0,0 +1 @@
+0
diff --git a/Tests/RunCMake/string/Timestamp-stderr.txt 
b/Tests/RunCMake/string/Timestamp-stderr.txt
new file mode 100644
index 000..c12b070
--- /dev/null
+++ b/Tests/RunCMake/string/Timestamp-stderr.txt
@@ -0,0 +1 @@
+RESULT=2005-08-07 23:19:49 Sun Aug 05 day=219 wd=0 week=32 %%I=11
diff --git a/Tests/RunCMake/string/Timestamp.cmake 
b/Tests/RunCMake/string/Timestamp.cmake
new file mode 100644
index 000..1232300
--- /dev/null
+++ b/Tests/RunCMake/string/Timestamp.cmake
@@ -0,0 +1,3 @@
+set(ENV{SOURCE_DATE_EPOCH} "1123456789")
+string(TIMESTAMP RESULT "%Y-%m-%d %H:%M:%S %a %b %y day=%j wd=%w week=%U 
%%I=%I" UTC)
+message("RESULT=${RESULT}")
diff --git a/Tests/RunCMake/string/TimestampEmpty-result.txt 
b/Tests/RunCMake/string/TimestampEmpty-result.txt
new file mode 100644
index 000..573541a
--- /dev/null
+++ 

[Cmake-commits] CMake branch, next, updated. v3.7.2-2348-g2a1a1cd

[Brad King]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "CMake".

The branch, next has been updated
   via  2a1a1cd66b63cac5cf2aff533bec4c35984a115c (commit)
   via  46177cceae13afa80baa87e6d84c17ed45ecb298 (commit)
  from  e2dadb0802b1e329d6b1df771ce6bfbe84b08a4b (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2a1a1cd66b63cac5cf2aff533bec4c35984a115c
commit 2a1a1cd66b63cac5cf2aff533bec4c35984a115c
Merge: e2dadb0 46177cc
Author: Brad King 
AuthorDate: Thu Jan 26 10:20:55 2017 -0500
Commit: CMake Topic Stage 
CommitDate: Thu Jan 26 10:20:55 2017 -0500

Merge topic 'topic-reproducible-build' into next

46177cce Revert topic 'topic-reproducible-build'


https://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=46177cceae13afa80baa87e6d84c17ed45ecb298
commit 46177cceae13afa80baa87e6d84c17ed45ecb298
Author: Brad King 
AuthorDate: Thu Jan 26 10:20:34 2017 -0500
Commit: Brad King 
CommitDate: Thu Jan 26 10:20:34 2017 -0500

Revert topic 'topic-reproducible-build'

diff --git a/Help/command/string.rst b/Help/command/string.rst
index 2c7847a..77538f6 100644
--- a/Help/command/string.rst
+++ b/Help/command/string.rst
@@ -329,12 +329,6 @@ If no explicit  is given it will 
default to:
 
 Write a string which can be used as an identifier in C.
 
-.. note::
-
-  If the ``SOURCE_DATE_EPOCH`` environment variable is set,
-  its value will be used instead of the current time.
-  See https://reproducible-builds.org/specs/source-date-epoch/ for details.
-
 UUID
 
 
diff --git a/Help/release/dev/SOURCE_DATE_EPOCH.rst 
b/Help/release/dev/SOURCE_DATE_EPOCH.rst
deleted file mode 100644
index 576e1da..000
--- a/Help/release/dev/SOURCE_DATE_EPOCH.rst
+++ /dev/null
@@ -1,5 +0,0 @@
-SOURCE_DATE_EPOCH
--
-
-* The :command:`string(TIMESTAMP)` will now honor the ``SOURCE_DATE_EPOCH``
-  environment variable and use its value instead of the current time.
diff --git a/Source/cmTimestamp.cxx b/Source/cmTimestamp.cxx
index 87677ec..4a97114 100644
--- a/Source/cmTimestamp.cxx
+++ b/Source/cmTimestamp.cxx
@@ -5,7 +5,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include "cmSystemTools.h"
 
@@ -13,16 +12,6 @@ std::string cmTimestamp::CurrentTime(const std::string& 
formatString,
  bool utcFlag)
 {
   time_t currentTimeT = time(CM_NULLPTR);
-  std::string source_date_epoch;
-  cmSystemTools::GetEnv("SOURCE_DATE_EPOCH", source_date_epoch);
-  if (!source_date_epoch.empty()) {
-std::istringstream iss(source_date_epoch);
-iss >> currentTimeT;
-if (iss.fail() || !iss.eof()) {
-  cmSystemTools::Error("Error parsing SOURCE_DATE_EPOCH as int");
-  exit(27);
-}
-  }
   if (currentTimeT == time_t(-1)) {
 return std::string();
   }
diff --git a/Tests/RunCMake/string/RunCMakeTest.cmake 
b/Tests/RunCMake/string/RunCMakeTest.cmake
index 38a77b0..8067d9d 100644
--- a/Tests/RunCMake/string/RunCMakeTest.cmake
+++ b/Tests/RunCMake/string/RunCMakeTest.cmake
@@ -6,11 +6,6 @@ run_cmake(AppendNoArgs)
 run_cmake(Concat)
 run_cmake(ConcatNoArgs)
 
-run_cmake(Timestamp)
-run_cmake(TimestampEmpty)
-run_cmake(TimestampInvalid)
-run_cmake(TimestampInvalid2)
-
 run_cmake(Uuid)
 run_cmake(UuidMissingNamespace)
 run_cmake(UuidMissingNamespaceValue)
diff --git a/Tests/RunCMake/string/Timestamp-result.txt 
b/Tests/RunCMake/string/Timestamp-result.txt
deleted file mode 100644
index 573541a..000
--- a/Tests/RunCMake/string/Timestamp-result.txt
+++ /dev/null
@@ -1 +0,0 @@
-0
diff --git a/Tests/RunCMake/string/Timestamp-stderr.txt 
b/Tests/RunCMake/string/Timestamp-stderr.txt
deleted file mode 100644
index 10952b2..000
--- a/Tests/RunCMake/string/Timestamp-stderr.txt
+++ /dev/null
@@ -1 +0,0 @@
-RESULT=2005-08-07 23:19:49
diff --git a/Tests/RunCMake/string/Timestamp.cmake 
b/Tests/RunCMake/string/Timestamp.cmake
deleted file mode 100644
index b698627..000
--- a/Tests/RunCMake/string/Timestamp.cmake
+++ /dev/null
@@ -1,3 +0,0 @@
-set(ENV{SOURCE_DATE_EPOCH} "1123456789")
-string(TIMESTAMP RESULT "%Y-%m-%d %H:%M:%S" UTC)
-message("RESULT=${RESULT}")
diff --git a/Tests/RunCMake/string/TimestampEmpty-result.txt 
b/Tests/RunCMake/string/TimestampEmpty-result.txt
deleted file mode 100644
index 573541a..000
--- a/Tests/RunCMake/string/TimestampEmpty-result.txt
+++ /dev/null
@@ -1 +0,0 @@
-0
diff --git a/Tests/RunCMake/string/TimestampEmpty-stderr.txt 
b/Tests/RunCMake/string/TimestampEmpty-stderr.txt
deleted file mode 100644
index 35cbd3c..000
--- a/Tests/RunCMake/string/TimestampEmpty-stderr.txt
+++ 

Re: [cmake-developers] Eclipse CDT Managed build

[Bøe , Sebastian]

Thank you for the warning and support. We would prefer to not maintain
a fork, but I have not been able to find any other technology
that is suitable.

For future reference. The intended use-case is for CMake to act 
as an engine in an IDE project generator solution similar to the below
solutions[0].

[0] 
http://start.atmel.com/
http://www.st.com/en/embedded-software/stm32cube-embedded-software.html



-Original Message-
From: Brad King [mailto:brad.k...@kitware.com] 
Sent: 26. januar 2017 14:18
To: Bøe, Sebastian 
Cc: ben.boec...@kitware.com; cmake-developers@cmake.org
Subject: Re: [cmake-developers] Eclipse CDT Managed build

On 01/26/2017 05:57 AM, Bøe, Sebastian wrote:
> I will investigate relocatable builds, because in spite of this not 
> being trivial, I think CMake still comes out as the best suited technology 
> for my use-case.

We once had an option to produce relative paths in the build system and it was 
a never ending mess of bugs.  Eventually it was ripped out.
It is unlikely we will accept changes to try to re-introduce such an option.

-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] Eclipse CDT Managed build

[Brad King]

On 01/26/2017 05:57 AM, Bøe, Sebastian wrote:
> I will investigate relocatable builds, because in spite of this not being
> trivial, I think CMake still comes out as the best suited technology for my 
> use-case.

We once had an option to produce relative paths in the build system
and it was a never ending mess of bugs.  Eventually it was ripped out.
It is unlikely we will accept changes to try to re-introduce such
an option.

-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] externalproject_add and generating sources

[Nicholas Braden]

You'll also want to build your own project with ExternalProject, and use
the DEPENDS option to control build order. This ensures that all
dependencies are fully installed before your own project is even
configured. The project with all the ExternalProject calls is typically
called a superbuild, and effectively becomes an optional convenience to
building your own project.

On Thu, Jan 26, 2017 at 3:23 AM, David Jobet  wrote:

> Hello,
>
> suppose I want to use protobuf and integrate it in my project with
> externalproject_add. (actually, I just have precompiled binaries and libs +
> header files, I don't have the full sources)
> Once the project has been 'built' (actually, installed by a custom
> rpm-like tool to a shared path), I can use the protoc compiler to generate
> protobuf c++ files (.pb.h and .pb.cpp files) from a .proto description file.
> I can add_dependencies so that the external project is built before
> projects depending on libprotobuf.a.
>
> However, I don't know how to do the same thing with .pb.h and .pb.cpp
> files which use a .proto file and the protoc compiler.
>
> make is fine with it, but ninja complains with an error like this :
> ninja: error: '/path_to_external_projects/protobuf/2.6.0.4/bin/protoc',
> needed by 'some_project/SomeFile.pb.h', missing and no known rule to make it
>
> how can I tell ninja that protoc is going to be provided by
> externalproject ?
> If I use byproducts, ninja is happy, but "ninja clean" deletes
> /path_to_external_projects/protobuf/2.6.0.4/bin/protoc.
> I don't want that to happen since /path_to_external_projects/protobuf/
> 2.6.0.4/bin/protoc is shared with other users.
>
> With regards
>
> David
> --
>
> 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
>
-- 

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

Re: [cmake-developers] Eclipse CDT Managed build

[Bøe , Sebastian]

I was not aware that this was a non-goal. Thank you
for feedback.

I am sorry if my use-case sounds foreign, but I can't use cmake server mode,
because I can't modify the IDE.

I will investigate relocatable builds, because in spite of this not being
trivial, I think CMake still comes out as the best suited technology for my 
use-case.

-Original Message-
From: Brad King [mailto:brad.k...@kitware.com] 
Sent: 25. januar 2017 17:38
To: Bøe, Sebastian 
Cc: ben.boec...@kitware.com; cmake-developers@cmake.org
Subject: Re: [cmake-developers] Eclipse CDT Managed build

On 01/25/2017 11:27 AM, Ben Boeckel wrote:
> not be trivial to get CMake to generate relocatable builds.

This is also an explicit non-goal of CMake.

>> after CMake generation the project can be configured through the IDE UI.

That is likely not compatible with CMake's notion of maintaining the build 
system.

This is why previous similar discussions resulted in the cmake server mode and 
in identifying the value of a declarative spec format that can be managed 
outside of CMake's language processor.

-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] CMake server-mode aborting

[Nils Gladitz]

On 01/26/2017 10:45 AM, Tobias Hunger wrote:


Hello CMake developers,

I have been using Qt Creator extensively with cmake server-mode for a
while now and am very happy with the results so far. Once the project
is initially configured by cmake it is really nice.

Today I started to look into a bug report that creator behaves
horribly when not all the dependencies of a project are available. In
that case the UI behaves entirely wrong (I just pushed a patch to
improve that on the Creator side into code review).

The root cause seems to be that during configure run CMake just
vanishes. Creator reports back that it crashed. I can unfortunately
not reproduce that problem with any of the CMakeLists.txt files I have
handy, so I am a bit lost at what to do.

Does any of you cmake experts have an idea what might go wrong? I
thought that maybe a MESSAGE(FATAL_ERROR ...) is triggered, causing
cmake server to terminate or something similar. Unfortunately that
does not seem to trigger the server to die for me:-/


I haven't really looked into server mode yet but for something that 
should crash cmake (server or otherwise):


function(foo)
foo()
endfunction()

foo()

Nils
--

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 server-mode aborting

[Tobias Hunger]

Hello CMake developers,

I have been using Qt Creator extensively with cmake server-mode for a
while now and am very happy with the results so far. Once the project
is initially configured by cmake it is really nice.

Today I started to look into a bug report that creator behaves
horribly when not all the dependencies of a project are available. In
that case the UI behaves entirely wrong (I just pushed a patch to
improve that on the Creator side into code review).

The root cause seems to be that during configure run CMake just
vanishes. Creator reports back that it crashed. I can unfortunately
not reproduce that problem with any of the CMakeLists.txt files I have
handy, so I am a bit lost at what to do.

Does any of you cmake experts have an idea what might go wrong? I
thought that maybe a MESSAGE(FATAL_ERROR ...) is triggered, causing
cmake server to terminate or something similar. Unfortunately that
does not seem to trigger the server to die for me:-/

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] Generate a file with a custom command as part of build

[doug livesey]

I'll have a play with that later. Thanks again for all your help.
   Doug.

On 25 January 2017 at 16:02, Michael Ellery  wrote:

>
> > On Jan 24, 2017, at 11:22 PM, doug livesey  wrote:
> >
> > Is there any way that I can make the files webpack compiles into
> dependencies for the Webpack task? So that any changes to those are picked
> up for recompilation?
> > No worries if not, I just thought it would be nice.
> >
>
> just add any files on which the command depends after the DEPENDS
> argument. I only added the one source file in that example, but you can add
> as many as are appropriate.
>
> -Mike
>
>
>
-- 

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

[CMake] externalproject_add and generating sources

[David Jobet]

Hello,

suppose I want to use protobuf and integrate it in my project with 
externalproject_add. (actually, I just have precompiled binaries and libs + 
header files, I don't have the full sources)
Once the project has been 'built' (actually, installed by a custom rpm-like 
tool to a shared path), I can use the protoc compiler to generate protobuf c++ 
files (.pb.h and .pb.cpp files) from a .proto description file.
I can add_dependencies so that the external project is built before projects 
depending on libprotobuf.a.

However, I don't know how to do the same thing with .pb.h and .pb.cpp files 
which use a .proto file and the protoc compiler.

make is fine with it, but ninja complains with an error like this :
ninja: error: '/path_to_external_projects/protobuf/2.6.0.4/bin/protoc', needed 
by 'some_project/SomeFile.pb.h', missing and no known rule to make it

how can I tell ninja that protoc is going to be provided by externalproject ?
If I use byproducts, ninja is happy, but "ninja clean" deletes 
/path_to_external_projects/protobuf/2.6.0.4/bin/protoc.
I don't want that to happen since 
/path_to_external_projects/protobuf/2.6.0.4/bin/protoc is shared with other 
users.

With regards

David
-- 

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

[CMake] Re : Re: Interfacing cmake with 3rdparties package manager, and exclude them from ninja clean

[David Jobet]

Hello,

I actually gave it a try : it works fine so long versions are hardcoded 
somewhere in the CMakeLists.txt and it make things really simpler.

But it does not work when version is extracted from git repository.
I came to realize I can extract this version number at build time (using 
add_custom_target and cmake -P), and I can even include a generated cmake file 
that contains the version number, but I don't know how to tell cmake to trigger 
a rebuild_cache anyway.
So I don't know how to make that behaviour "dynamic".
Any idea ?

With regards

David

- Tamás Kenéz  a écrit :
> Maybe executing your script in configure time (execute_process)?
> 
> On Fri, Jan 20, 2017 at 4:36 PM,  wrote:
> 
> > Hello,
> >
> > I'm working on a project where some of our libs depend on custom build of
> > some external libraries.
> > Those external libraries are managed through a repository manager similar
> > to rpm (redhat package manager) which allows us to retrieve pre-compiled
> > versions with related header files. (similar to devel packages)
> >
> > The catch is we want libraries to be downloaded automatically to a shared
> > (multiple users) local dir __AND__ we don't want them to be cleaned.
> > (because another user could be using it).
> >
> > I've tried add_custom_command but files disappear with make clean.
> > I've tried to set NO_CUSTOM_CLEAN, that works with make but not with ninja.
> >
> > I've tried to chain add_custom_target to download the file and
> > add_dependencies, again, this works with make but not with ninja (ninja
> > does not know how to create protocol buffer compiler "protoc" for example
> > since it's not the output of any command he knows)
> >
> > I've tried externalproject_add with BUILD_BYPRODUCTS but it looks like
> > ninja still clean the downloaded files.
> >
> > Any idea on how to make ninja not clean those downloaded files (we use
> > generators like protoc, libraries and header files)
> >
> > With regards
> >
> > David
> >
> > PS : in my add_custom_command/add_custom_target, I invoke "cmake -P" on a
> > custom cmake script with 2 args. The first arg is a file to test for
> > existence, the second one is the parameter to our custom "rpm" to download
> > the package.
> >
> > --
> >
> > 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
> >

-- 

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