On 2019-10-10 18:21-0400 Paul Smith wrote:
On Thu, 2019-10-10 at 14:57 -0400, Robert Maynard via CMake wrote:
* The "UNITY_BUILD" target property was added to tell generators to
batch include source files for faster compilation times.
Are there any instructions on how to make this work? I
t a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 404b475..f7646c9 100644
--- a/Source/CMakeVersion.cmake
+++ b/Source/CMakeVersion.cmake
@@ -1,7 +1,7 @@
# CMake version number components.
set(CMake_VERSION_MAJOR 3)
set(CMake_VERSION_MINOR 16)
-set(CMake_VERSION_PATCH 20191010)
+set(CMake_VER
On Thu, 2019-10-10 at 14:57 -0400, Robert Maynard via CMake wrote:
> * The "UNITY_BUILD" target property was added to tell generators to
> batch include source files for faster compilation times.
For some reason this didn't work with my actual cmake environment, but
I could enable it on a
On Thu, 2019-10-10 at 14:57 -0400, Robert Maynard via CMake wrote:
> * The "UNITY_BUILD" target property was added to tell generators to
> batch include source files for faster compilation times.
Are there any instructions on how to make this work? I tried this:
cmake -G 'Unix Makefiles'
I am proud to announce the first CMake 3.16 release candidate.
https://cmake.org/download/
Documentation is available at:
https://cmake.org/cmake/help/v3.16
Release notes appear below and are also published at
https://cmake.org/cmake/help/v3.16/release/3.16.html
Some of the more
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 8d2f18af3268920412621e98e527830faa763448 (commit)
via
I have [opened an issue on the
bugtracker](https://gitlab.kitware.com/cmake/cmake/issues/19823) concerning
this documentation bug.
Alan
__
Alan W. Irwin
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net);
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 annotated tag, v3.16.0-rc1 has been created
at b0030385395d25452fd043fff69c603df363b328 (tag)
tagging
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 afdb354ac77818604dfed8ef416031a12ab49a48 (commit)
via
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, release has been updated
via 9150c818b7d2afb868575fcb2e0c9ba62b9d7f85 (commit)
from
On Thu, 10 Oct 2019, Eric Noulard wrote:
...
> with patchelf is works with an intriguing warning:
> warning: working around a Linux kernel bug by creating a hole of 2093056
> bytes in ‘/path/to/executable’
>
> which seems to be a resolved issue:
> https://github.com/NixOS/patchelf/issues/92
>
>
On Thu, 10 Oct 2019, Eric Noulard wrote:
...
> No rpath and using "only" LD_LIBRARY_PATH is not feasible in that case?
> Removing rpath is easy; chrpath -d lib_or_exe
You could but, to avoid a maintenance headache, you'd normally end up
getting the environment module to load any prereq
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, release has been updated
via 580e322dcbc3cfe8cbe08491564fe2aeb727b811 (commit)
via
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 e3b9d125ef5cd766b05f0354ca817ebfc7b82a42 (commit)
via
ping ?
On 2019-10-07 12:47 p.m., stefan wrote:
Hi,
can you reproduce my observations ? I'm I doing something wrong or is
there indeed an issue with CMake ? Should I follow up with a bug report ?
Thanks,
On 2019-10-04 2:20 p.m., stefan wrote:
On 2019-10-03 5:24 p.m., Kyle Edwards wrote:
From: Eric Noulard
Sent: 10 October 2019 14:43
To: Zakrzewski, Jakub
Cc: cmake@cmake.org
Subject: Re: [CMake] cmake end user vs. developer rpath handling
> So I was wrong, thank you for your honest question Jakub.
> I learned something usefull thanks to you.
Le jeu. 10 oct. 2019 à 14:30, Eric Noulard a
écrit :
>
>
> Le jeu. 10 oct. 2019 à 14:02, Zakrzewski, Jakub <
> jakub.zakrzew...@scheer-group.com> a écrit :
>
>> --
>> *From:* CMake on behalf of Eric Noulard <
>> eric.noul...@gmail.com>
>> *Sent:* 10 October 2019
Le jeu. 10 oct. 2019 à 14:02, Zakrzewski, Jakub <
jakub.zakrzew...@scheer-group.com> a écrit :
> --
> *From:* CMake on behalf of Eric Noulard <
> eric.noul...@gmail.com>
> *Sent:* 10 October 2019 12:05
> *To:* DIXON, MARK C.
> *Cc:* cmake@cmake.org
> *Subject:* [DKIM]
From: CMake on behalf of Eric Noulard
Sent: 10 October 2019 12:05
To: DIXON, MARK C.
Cc: cmake@cmake.org
Subject: [DKIM] Re: [CMake] cm?ake end user vs. developer rpath handling
> No they can't because the maximum size is burried into the binary ELF file,
>
Le jeu. 10 oct. 2019 à 13:08, DIXON, MARK C. a
écrit :
> On Thu, 10 Oct 2019, Eric Noulard wrote:
> ...
> > No they can't because the maximum size is burried into the binary ELF
> file,
> > that why CMake "reserve" some space with many ";;;" in order to replace
> > BUILD_RPATH with INSTALL_RPATH
On Thu, 10 Oct 2019, Eric Noulard wrote:
...
> No they can't because the maximum size is burried into the binary ELF file,
> that why CMake "reserve" some space with many ";;;" in order to replace
> BUILD_RPATH with INSTALL_RPATH when doing
> 'install'.
Hi Eric,
Interesting - any ideas on how
Hi again
I just tried adding those additional two options, but I am getting the same
error with lintian.
Is there something wrong in my shlibs or control file?
Thanks
Matthew
From: CMake on behalf of "Gillman, Matthew"
Date: Thursday, 10 October 2019 at 10:58
To: Kerstin Keller ,
Le jeu. 10 oct. 2019 à 11:58, Gillman, Matthew a
écrit :
> Hi Kerstin
>
>
>
> Sorry, I forgot to list them. Right now I only have the following set:
>
>
>
> SET(CPACK_GENERATOR "DEB")
>
> SET(CPACK_DEBIAN_PACKAGE_MAINTAINER "Me ")
>
> INCLUDE(CPack)
>
>
>
> I will try adding the two you suggest
Le jeu. 10 oct. 2019 à 10:36, DIXON, MARK C. a
écrit :
> On Wed, 9 Oct 2019, Aaron Cohen wrote:
>
> > Is it not feasible to just let the build system do whatever it is going
> to
> > and use "chrpath" or "patchelf" to change the rpath after-the-fact?
>
> Thanks for the suggestion, but I need to
Hi Kerstin
Sorry, I forgot to list them. Right now I only have the following set:
SET(CPACK_GENERATOR "DEB")
SET(CPACK_DEBIAN_PACKAGE_MAINTAINER "Me mailto:m...@me.com>>")
INCLUDE(CPack)
I will try adding the two you suggest and see how it goes, but I wouldn’t be
surprised if there were others
Hi,
what CPACK_DEBIAN_* options have you set and to what values have you set
them?
I guess you're both using:
set(CPACK_DEBIAN_PACKAGE_SHLIBDEPS ON)
set(CPACK_DEBIAN_PACKAGE_GENERATE_SHLIBS ON)
When I generate the file for my lib it looks a bit different (e.g. it pins
the package to a certain
On Wed, 9 Oct 2019, Aaron Cohen wrote:
> Is it not feasible to just let the build system do whatever it is going to
> and use "chrpath" or "patchelf" to change the rpath after-the-fact?
Thanks for the suggestion, but I need to add directories to the rpath: I
believe that neither utility allows
It's great that cpack can generate different packages - in my case, a .deb file
for Debian.
But if you then want to submit the generated .deb file to be part of Debian's
official release, you have to run the lintian tool, and make sure you pass its
checks. I have managed manually to fix some
28 matches
Mail list logo
