On 3. Oct, 2010, at 23:53 , Mateusz Loskot wrote:
> On 03/10/10 22:27, J Decker wrote:
>> On Sun, Oct 3, 2010 at 10:28 AM, Mateusz Loskot wrote:
>>> Hi,
>>>
>>> I understand what the manual [1] says about LOCATION property that it is
>>> more or less deprecated. Is that right?
>>>
>>> I'm buil
On 03/10/10 22:27, J Decker wrote:
> On Sun, Oct 3, 2010 at 10:28 AM, Mateusz Loskot wrote:
>> Hi,
>>
>> I understand what the manual [1] says about LOCATION property that it is
>> more or less deprecated. Is that right?
>>
>> I'm building software (shared libraries and executables) on both, Linux
Hello all,
I've created a draft patch adding the CMake support for configuring
Intel Projects in Visual Studio:
http://public.kitware.com/Bug/view.php?id=6929
There are still few open questions, but I'd like to hear the comments
regarding the implementation.
As I don't know CMake internals very w
Hi,
I understand what the manual [1] says about LOCATION property that it is
more or less deprecated. Is that right?
I'm building software (shared libraries and executables) on both, Linux
and Windows (using VS 2005, 2008, 2010) and I'm trying to find out what
would be portable way to get target
Am Sonntag 03 Oktober 2010, 14:15:41 schrieb Paul McEnery:
> The solution was to set CMAKE_EXE_LINKER_FLAGS using "-Wl,--as-needed".
That is actually only a work-around. Pkg-config can handle the difference
between static linking and dynamic linking but you have to tell it what is
what. However,
Resolved!
The solution was to set CMAKE_EXE_LINKER_FLAGS using "-Wl,--as-needed".
CMakeLists.txt:
==
cmake_minimum_required (VERSION 2.6)
project(galinette)
set(GALINETTE_VERSION "1.1" CACHE STRING
"Software version" FORCE)
set(bindir
On 2 October 2010 23:19, Andreas Pakulat wrote:
[...]
>
> Thats because a link-interface for an executable doesn't make the
> slightest sense. The link-interface in cmake for a library target foo,
> defines which libraries should automatically get into the linker-call
> when linking some other tar