On 04/04/14 12:45, Nils Gladitz wrote:
> CMake execution time of one of my projects jumps from 0m6.121s
> (2.8.12.2) to 1m5.084s (3.0.20140404-gce0aa).
>
> Most time seems to be spend after "-- Configuring done".
>
> Any ideas?
>
> Nils
Maybe this http://public.kitware.com/Bug/view.php?id=14758 has
However, is there a
way to easily parse the output of "type"? The "which" command simply
returns the command it will execute or an empty string if there's no
match. With "type", I've seen different outputs, like:
$ type ls
ls is aliased to `ls --color=auto&#
On 01/12/13 09:34, Nils Gladitz wrote:
> On 30.11.2013 20:49, Marcel Loose (Astron) wrote:
>> According to the CMake documentation, the TARGET property LOCATION for a
>> non-imported target is provided for compatibility with CMake 2.4 and
>> below. My question is: are there a
target is provided for compatibility with CMake 2.4 and
below. My question is: are there any plans to deprecate this property? I
want to know, because AFAIK, the only way to determine the full path to
a built target is to use this property.
Best regards,
Marcel Loose.
-BEGIN PGP SIGNATURE
to use a test property three years ago (see issue
#8466). At that time David was very much against it, fearing to find "a
***huueee*** can of worms right underneath the surface." Seems
I'm slowly getting more fellow thinkers ;)
Regards,
Marcel Loose.
<>--
Pow
Hi Stephen,
On Fri, 2012-02-17 at 12:06 +0100, Stephen Kelly wrote:
-- 8< 8< 8< 8< 8< 8< 8< 8< 8< --
> diff --git a/templates/tests/CMakeLists.txt
b/templates/tests/CMakeLists.txt
> index d2e37d2..ad471c7 100644
> --- a/templates/tests/CMakeLists.txt
> +++
E_SKIP_RPATH so that it leaves the RPATH on in the
build
> tree, but not in the install tree, IMO makes sense. It's also a good
sign that
> Sune, a Debian packager, says it doesn't matter for Debian what
happens in the
> build tree, but I don't know whether it would be ok for eve
; cmake-developers@cmake.org
> http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Hi David,
Unfortunately, I won't have time to work on issue 10201 in the coming
week. So could you please defer it to the next release? Thanks.
Best regards,
Marcel Lo
Hi Brad,
>>> On 19-11-2010 at 13:41, in message <4ce6708a.8020...@kitware.com>,
Brad King
wrote:
> On 11/19/2010 03:56 AM, Marcel Loose wrote:
>> Slightly off-topic: I couldn't find any references to this
information
>> in the CMake manual.
>
> Tha
>>> On 18-11-2010 at 20:32, in message
<201011182032.35251.neund...@kde.org>,
Alexander Neundorf wrote:
> On Thursday 18 November 2010, Marcel Loose wrote:
> ...
>> Hi all,
>>
>> I've been following this discussion with interest for quite a while
>>> On 18-11-2010 at 14:43, in message <4ce52d91.7070...@kitware.com>,
Brad King
wrote:
> On 11/18/2010 04:29 AM, Marcel Loose wrote:
>> I've been following this discussion with interest for quite a while.
I
>> was wondering if both worlds could be united
nd as soon as this is out, use the new policy and see
> whether/how
>> much breakage there is.
>>
>> Alex
>>
>
> We may have discussed it, but it was a while ago, and my brain can't
> recall specific details about how we arrived at this point.
>
> This poli
Hi David,
I've got one more, one that I just entered in Mantis.
#11410 - Result of IF() is inconsistent
Regards,
Marcel Loose.
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/
13 matches
Mail list logo
