Hello all,
The latest cmake versions from the git tree seem to trigger an odd
problem in my build. This is my configuration:
Ubuntu 12.10
gcc (Ubuntu/Linaro 4.7.2-2ubuntu1) 4.7.2
GNU Make 3.81 / Ninja 1.4.0.git
Qt sdk 4.7.4
I have a project which uses Qt. When I generate the buildsystem, then
mu
Micha Hergarden wrote:
> I have checked out and build the most recent versions to figure out when
> this phenomena is introduced, and have narrowed it down to the following
> commit :
> 4b989d5f158e5135bf543438af00b03db0102ade
Hi,
Thanks for investigating and reporting!
> My questions:
> - I any
Steve Wilson wrote:
> Ok, I’ve pushed the new changes.
Are you sure? Looking at the top commit, I don't see any change to the
ExportImport test.
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Ple
On 02/05/2014 10:15 AM, Stephen Kelly wrote:
> Micha Hergarden wrote:
>> I have checked out and build the most recent versions to figure out when
>> this phenomena is introduced, and have narrowed it down to the following
>> commit :
>> 4b989d5f158e5135bf543438af00b03db0102ade
> Hi,
>
> Thanks for
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=14736
==
Reported By:lando
Assigned To:
=
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=14737
==
Reported By:Alex Merry
Assigned To:
Let’s try all this again.I have a couple questions.
On Feb 4, 2014, at 3:41 AM, Stephen Kelly wrote:
> 2) The change to cmNinjaNormalTargetGenerator seems incorrect. Should
> linkFlags should be used with AddLinkOptions?
Do you mean linkFlags vs vars[“LINK_FLAGS”]? I suppose it could
Steve Wilson wrote:
> Let’s try all this again.I have a couple questions.
>
> On Feb 4, 2014, at 3:41 AM, Stephen Kelly
> wrote:
>
>> 2) The change to cmNinjaNormalTargetGenerator seems incorrect. Should
>> linkFlags should be used with AddLinkOptions?
>
> Do you mean linkFlags vs vars[“LI
On Feb 5, 2014, at 10:51 AM, Stephen Kelly wrote:
>>> 4) Tests should avoid bad practices like using target_link_options to add
>>> libraries. Instead try to choose suitable link flags for the tests.
>>
>> I’m having a little trouble with your notion of ‘bad practices.’ I’m
>> sure you have g
In the documentation for CMAKE_CONFIGURATION_TYPES it states:
“… but can be extended to provide other build types. … “
How would one provide other build types?
signature.asc
Description: Message signed with OpenPGP using GPGMail
--
Powered by www.kitware.com
Visit other Kitware open-source
On 2014-02-03 18:13, Alex Merry wrote:
+also inspects header files named ``.`` and ``.`` for
Am I blind, or did you list the same header pattern twice? (I think one
of these was meant to have a '_p'?)
--
Matthew
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
ht
On Wed, Feb 05, 2014 at 12:00:41 -0700, Steve Wilson wrote:
> In the documentation for CMAKE_CONFIGURATION_TYPES it states:
>
> “… but can be extended to provide other build types. … “
>
> How would one provide other build types?
It's just a list with a default of
"Release;RelWithDebInfo;RelMinS
Steve Wilson wrote:
> Now, everything you have said about not encouraging this kind of usage for
> target_link_options() and libraries, etc… is valid. However, does that
> standard apply to tests. Are tests just tests?
Admittedly, the target_compile_options tests use defines as test input. I'
On Feb 5, 2014, at 3:06 PM, Stephen Kelly wrote:
> Steve Wilson wrote:
>
>> Now, everything you have said about not encouraging this kind of usage for
>> target_link_options() and libraries, etc… is valid. However, does that
>> standard apply to tests. Are tests just tests?
>
> Admittedly,
Steve Wilson wrote:
> I’m not trying to push for this type of test of using libraries with
> target_link_options or add_link_options. (I’m already working on changes
> on the order that you suggested). My question has evolved more into the
> question of ‘what are first principles for tests?'
I d
15 matches
Mail list logo