Hi,
(Pardon the length; skip to end to see what I am proposing to change. Below
is justification why.)
I have found it annoyingly difficult to set up an environment for a build
when using ExternalProject_Add. This seems to be needed when creating a
superbuild that uses several different
On 08/07/2015 07:38 PM, Stephen Kelly wrote:
Chris Bieneman wrote:
One big things I'm working on is improving the way we build our runtime
libraries. These libraries are built for the targets that the compiler
supports generating code for, so they can use different architectures,
headers, and
On 08/10/2015 10:21 AM, rle...@codelibre.net wrote:
I often configure projects with an empty install prefix and install with
DESTDIR set. This works for most projects and they are relocatable.
So long as projects don't contain internal references that hard-code
the prefix then relocatable
On 08/10/2015 11:29 AM, Robert Goulet wrote:
could it be a problem of recursion?
Yes, that is exactly the problem.
perhaps it would be better to check for recursion directly in
the generator expressions evaluation
Some generator expressions do support recursion. While some
checks may be
Hi guys, I'm back from my vacation and I plan to look at the issue this week.
I am wondering, could it be a problem of recursion? Because if it was the case,
then perhaps it would be better to check for recursion directly in the
generator expressions evaluation function and have CMake error out
Regarding branch stage/add-link-search-static-properties-defaults
When working on a recent branch to allow default initialization of the
target properties LINK_SEARCH_(START|END)_STATIC with a corresponding
CMAKE_* variable, I encountered what I believe to be a bug in how the HP-UX
toolchains are
the C compiler is getting used as the linker for shared libs
It looks like this has been the case since CMake 2.8.7:
Easy then. I'll just fix it to use -Wl,-a like all the others. Thanks.
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
On 08/10/2015 01:21 PM, Chuck Atkins wrote:
According to the compiler reference manual, -Wl,-a,default will search
for shared first, then use static if the shared lib is not present.
Changing this to -Wl,-a,shared will make the search use shared libraries
exclusively, which is how all the
A related question is whether those are even the correct flags for the
CMAKE_${type}_LINK_DYNAMIC_${lang}_FLAGS. According to the compiler
reference manual, -Wl,-a,default will search for shared first, then use
static if the shared lib is not present. Changing this to -Wl,-a,shared
will make the
On 08/10/2015 11:30 AM, Chuck Atkins wrote:
the C compiler is getting used as the linker for shared libs
It looks like this has been the case since CMake 2.8.7:
HP: Drive shared library linking with compiler front end
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5720e1f6
but the
Please find attached a patch fixing ExternalProject_Add() which update
mercurial repositories _twice_, which can lead to too long cloning
transactions
(in particular when there are subrepos in the default branch),
which can lead transaction abort by repository servers.
I found the issue in such
We need to distinguish between the original MSYS and MSYS2 for
purposes of this discussion. IIUC MSYS2 is a full environment
like Cygwin. In the Distinguishing MSYS2 thread we established
that CMake should be built for running under MSYS2 and link to
the msys-2.0.dll runtime in order to
On 08/07/2015 09:47 PM, Greg Jung wrote:
Here is a patch that incorporates mingw/msys run via MSYS Makefiles
generator to obtain the system name via uname -s.
Thanks. Is this meant for use when running on MSYS2? Is
#if defined(__MSYS__) the official preprocessing condition for
targeting the
I often configure projects with an empty install prefix and install with
DESTDIR set. This works for most projects and they are relocatable.
However, the configure_package_config_file function breaks if this is
done:
CMake Error at cmake/CMakePackageConfigHelpers.cmake:254 (file):
file
14 matches
Mail list logo
