t a/Source/CMakeVersion.cmake b/Source/CMakeVersion.cmake
index 63f1dce..a3d46bc 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 14)
-set(CMake_VERSION_PATCH 20190530)
+set(CMake_VER
El 30/5/19 a las 21:36, Zan Lynx escribió:
RPM files are not cpio. They contain a cpio. Use rpm2cpio as a filter.
Thanks for that. Using:
rpm2cpio mrViewer-v5.0.7-Linux-64.rpm | cpio -idmv
I can extract all the contents of the archive with no errors.
However, rpm -i bails out with a cpio:
On May 30, 2019 5:21:59 PM MST, "Gonzalo Garramuño" wrote:
>
>El 30/5/19 a las 12:51, Gonzalo Garramuño escribió:
>> rpm -ql mrViewer-v5.0.6-Linux-64.rpm
>
>If I run cpio -i < mrViewer-v5.0.6-Linux-64.rpm
>
>I get a bunch of warnings of Incorrect numbers (and garbage) and Cannot
>
>make mknod:
El 30/5/19 a las 12:51, Gonzalo Garramuño escribió:
rpm -ql mrViewer-v5.0.6-Linux-64.rpm
If I run cpio -i < mrViewer-v5.0.6-Linux-64.rpm
I get a bunch of warnings of Incorrect numbers (and garbage) and Cannot
make mknod: the multibyte or extended character is incomplete or
invalid, and
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 c0b560f6641ab406894864c2534740bd1fd538a4 (commit)
via
On 5/30/19 1:25 PM, Marc Herbert wrote:
> I suspect the behaviour I described is also considered a bug
Yes, it is a bug and is related to 16228. The problem is that
there is a poor implementation of support for the use case
described in that issue, and the details of that implementation
leak out
Thanks Brad for the reference, really appreciated. Some of 16228 seems
relevant. Other parts unfortunately not because 16228:
- tries to deal with all the crazy ways users can use symbolic links,
including relative paths and relative links,
- tries to deal with all the ways users can invoke cmake,
El 30/5/19 a las 12:51, Gonzalo Garramuño escribió:
I have a CMakeLists.txt (extract) with the following commands:
SET(CPACK_GENERATOR DEB RPM TGZ )
# SET the installation directory.
SET(CPACK_SET_DESTDIR true) # Needed
SET(CPACK_INSTALL_PREFIX /usr/local/${mrViewerShortName})
I have a CMakeLists.txt (extract) with the following commands:
SET(CPACK_GENERATOR DEB RPM TGZ )
# SET the installation directory.
SET(CPACK_SET_DESTDIR true) # Needed
SET(CPACK_INSTALL_PREFIX /usr/local/${mrViewerShortName})
SET(CPACK_RPM_PACKAGE_NAME mrViewer)
Using CMake 3.12.2.
Consider the following project:
project(myproject)
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib)
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
set(CMAKE_INSTALL_PREFIX
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 7a8a24d0284856b7b38037884d0b17a1de7a9926 (commit)
via
On 5/30/19 3:22 AM, Marc Herbert wrote:
> IF the current directory is a parent of the -S argument AND
> one component of the current directory is a symbolic link THEN
> the leading part of the -S argument is overridden using that
> symbolic link.
See this issue:
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 5bb1e9a382f7ed4d42e799581acaa63a909b7b5a (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 a6a04cc446e67017e74e294a4aef84e9e8da4323 (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 05af1770a05e00d67f12f4e3ef294360d8d6480d (commit)
via
Hi,
I discovered a very unexpected -S behaviour and I'd like to know whether
it's a bug or a feature.
IF the current directory is a parent of the -S argument AND one component
of the current directory is a symbolic link THEN the leading part of the -S
argument is overridden using that symbolic
16 matches
Mail list logo
