Hi,
I apologise for the late reply. I wasn't at my computer for the past week.
2015-08-19 21:08 GMT+02:00 Роман Донченко d...@corrigendum.ru:
Currently, the only case is for simple variable values (not containing any
CMake-special characters and not determined by CPack itself).
In CPackRPM
Hallo,
On 13/08/15 12:56, Ruslan Baratov wrote:
On 13-Aug-15 08:46, Gregor Jasny wrote:
On 13/08/15 01:44, Ruslan Baratov via cmake-developers wrote:
Sending patches with fix. Now it's possible to install simulator
libraries by:
cmake --build _builds --config Release --target install --
I agree with David.
Offering the possibility to manage native paths in an easy way is a very good
enhancement (Today, I rely on some specific actions when I am on Win32 to
manage native path for ONE specific step of ExternalProject) BUT, offering only
the alternative to have NONE or ALL paths
On 25/08/15 19:01, Brad King wrote:
On 08/24/2015 04:43 PM, Gregor Jasny via cmake-developers wrote:
I just pushed a topic branch to add support for Xcode 7 TDB files:
http://www.cmake.org/gitweb?p=stage/cmake.git;a=shortlog;h=refs/heads/apple-tbd-stubs
Thanks. Please merge to 'next' when
Chuck Atkins wrote:
I've implemented a new policy, CMP0065, to restrict the addition of
CMAKE_SHARED_LIBRARY_LINK_LANG_FLAGS to executables to only when the
ENABLE_EXPORTS target property is set. This should allow us to preserve
backwards compatibility in the places it breaks existing
Dear all,
We have received funding from the Greek Free/Open Source Software Society
https://ellak.gr/greek-free-open-source-software-societygfoss/ to develop
Docker integration to CMake and CPack. As a first step, we have created a
simple questionaire for collecting user and developer input
The following issue has been SUBMITTED.
==
http://www.cmake.org/Bug/view.php?id=15713
==
Reported By:ovz
Assigned To:
Hi,
I see that I'm a bit late to the party... Wasn't at my computer for
the past few days.
Now if you find a way to set root ownership in archive created by
CPackDeb then every deb package
will have those right.
Again two solutions:
- using system tar with the proper uid/gid options
-
Awesome - in that case I'll use this built-in support instead of spending
time on writing a python script to call from add_custom_command().
It's not officially documented yet ( http://bit.ly/1MOzB0S ), but I can use
the link you sent ( http://bit.ly/1UdL3nc ) for documentation.
I'm not sure
Would you prefer to have a switch for each *_DIR variable for all target steps,
or a common switch but for each target step, like the new USE_TERMINAL switches
in the master?
Von: CHEVRIER, Marc [marc.chevr...@sap.com]
Gesendet: Mittwoch, 26. August 2015
Le 26/08/15 01:07, Eric Noulard a écrit :
Right, but I am more concerned about the proper way of doing it and
not the difficulty. From all this discussion, using fakeroot
directly does not look to me as the right solution for having root
in the tar, in the first place. So if we
I see. Added native-style path replacements for SOURCE_NATIVE_DIR and so on.
Also extended the documentation accordingly.
Von: CHEVRIER, Marc [marc.chevr...@sap.com]
Gesendet: Mittwoch, 26. August 2015 10:26
An: Kislinskiy, Stefan; David Cole
Cc:
I didn’t even think about switches. I don’t think they are required.
Adding the capability to handle paths in native format seems enough.
Example: I want to use a specific tool for the build step which supports only
native paths
ExternalProjet_add (
….
SOURCE_DIR c:/sources/my_project
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=15712
==
Reported By:Michael Priestman
Assigned To:
Hi Peter,
Note the commit Brad mentioned in another thread:
VS: Add more Nsight Tegra generator Android property settings
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=8c0afaf4
It adds the ability to set both Native Library Directories and Native Library
Dependencies, among other
Hello,
I am using the find_package() command to load settings for the Intel Math
Kernel Library (MKL). This works through a custom FindMKL.cmake module that
I've made for myself.
However, when looking at:
https://software.intel.com/en-us/articles/intel-mkl-link-line-advisor/
I can tell that what
I've implemented a new policy, CMP0065, to restrict the addition of
CMAKE_SHARED_LIBRARY_LINK_LANG_FLAGS to executables to only when the
ENABLE_EXPORTS target property is set. This should allow us to preserve
backwards compatibility in the places it breaks existing binaries but allow
us to remove
-Original Message-
From: cmake-developers [mailto:cmake-developers-boun...@cmake.org]
On Behalf Of Kislinskiy, Stefan
Sent: Wednesday, August 26, 2015 10:03
To: CHEVRIER, Marc; David Cole
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] ExternalProject: Use native
We sometime struggled to get it working, but we never had to resort to using a
FindMKL -- FindBLAS and FindLAPACK work just fine for us, provided we do things
correctly.
So long as we have sourced the mklvars script that ships with Intel MKL and we
put:
BLA_VENDOR =Intel10_64lp_seq ccmake
Maybe
[TARGET_PROPERTIES prop1 value1 [prop1 value1]... ]
makes sense instead?
That would allow setting ANDROID_API, WIN32_EXECUTABLE etc.
Good idea! I actually do like that better, but it's outside the scope of
this change. For now I'll remove the ENABLE_EXPORTS but still propagate
Domen Vrankar domen.vran...@gmail.com писал в своём письме Wed, 26 Aug
2015 22:27:43 +0300:
2015-08-19 21:08 GMT+02:00 Роман Донченко d...@corrigendum.ru:
Currently, the only case is for simple variable values (not containing
any
CMake-special characters and not determined by CPack
21 matches
Mail list logo
