Am Samstag 01 Oktober 2011, 12:31:36 schrieb Stephen Kelly:
Rolf Eike Beer wrote:
Hi,
In KDE we set the LINK_INTERFACE_LIBRARIES to empty in a wrapper
around
add_library. The reason is to reduce the number of libraries which are
linked to by default - developers have to be explicit
Rolf Eike Beer wrote:
The tricky part of this is to tell CMake to not enforce the implicit
dependencies to be exported when creating an export file for targets
created with this property enabled. Or better: to not enforce _any_
dependencies of a shared library to be exported then.
I
Am Samstag 01 Oktober 2011, 13:57:09 schrieb Stephen Kelly:
Rolf Eike Beer wrote:
The tricky part of this is to tell CMake to not enforce the
implicit
dependencies to be exported when creating an export file for
targets
created with this property enabled. Or better: to not enforce
Rolf Eike Beer wrote:
Am Samstag 01 Oktober 2011, 13:57:09 schrieb Stephen Kelly:
Rolf Eike Beer wrote:
The tricky part of this is to tell CMake to not enforce the
implicit
dependencies to be exported when creating an export file for
targets
created with this property enabled. Or
On Sat, Oct 1, 2011 at 6:37 AM, Stephen Kelly steve...@gmail.com wrote:
Hi,
Currently setting the link dependencies and the link interface involves a
lot of repetition. It is necessary to call target_link_libraries twice:
target_link_libraries(radiobuttonmodel
${QT_QTCORE_LIBRARIES}
Hi David,
This is related to my patch to set the link_interface_libraries to empty and
to:
http://thread.gmane.org/gmane.comp.kde.devel.buildsystem/6622/focus=72030
Quoting:
Setting LINK_INTERFACE_LIBRARIES to empty is still needed and wanted.
By default, all libraries a target is linked
I think it would be good to do what you propose, eventually. Emphasis on the
eventually, unless there's a burning need for it on the part of a
contributor.
However, the KWSys files are not directly push-able into our git repository:
we have a server-side hook that rejects pushes containing
Hi,
I just merged the branch HandleCMAKE_CXX_COMPILER_ARG1InEclipse into next, it
fixes http://public.kitware.com/Bug/view.php?id=12392 .
It's a small patch, and helps people using Eclipse + cmake + ccache.
Can this still make it into 2.8.6 please ?
Thanks
Alex
--
Powered by www.kitware.com
Brad and Bill and I will look at this Monday.
We are closing in on the final 2.8.6 release. If we take changes Monday,
we'll merge them, await the dashboard results on Tuesday morning, and then
build the final 2.8.6. If we take no changes, I'll build 2.8.6 on Monday.
You must admit, this fix
On Saturday 01 October 2011, David Cole wrote:
Brad and Bill and I will look at this Monday.
We are closing in on the final 2.8.6 release. If we take changes Monday,
we'll merge them, await the dashboard results on Tuesday morning, and then
build the final 2.8.6. If we take no changes, I'll
On 2011-10-01 20:13+0200 Alexander Neundorf wrote:
On Saturday 01 October 2011, David Cole wrote:
Brad and Bill and I will look at this Monday.
We are closing in on the final 2.8.6 release. If we take changes Monday,
we'll merge them, await the dashboard results on Tuesday morning, and then
On Sa., 1. Okt. 2011 18:40:09 CEST, Alexander Neundorf neund...@kde.org
wrote:
If library bar internally uses symbols from foo,
it needs to link against foo.
Correct.
But if bar doesn't expose symbols from foo in its
interface, and my executable hello links against bar, it doesn't also
On Oct 1, 2011, at 4:48 PM, Rolf Eike Beer wrote:
On Sa., 1. Okt. 2011 18:40:09 CEST, Alexander Neundorf neund...@kde.org
wrote:
If library bar internally uses symbols from foo,
it needs to link against foo.
Correct.
But if bar doesn't expose symbols from foo in its
interface,
that's the problem: you don't know neither file name nor it's location,
especially in multi-configuration generators.
It's also bad idea to mix build and install steps. Install command doesn't
understand generators expressions.
If it were possible to emulate vs behavior for gcc things would be
Am Samstag 01 Oktober 2011, 06:11:44 schrieb Michael Hertling:
On 09/30/2011 08:39 AM, Rolf Eike Beer wrote:
On 09/29/2011 06:15 AM, Yuri Timenkov wrote:
When I was investigating similar problem, I found alternative
approach
at
On 30.09.2011 19:16, Eric Noulard wrote:
2011/9/30 Alexander Neundorfa.neundorf-w...@gmx.net:
Summary:
builddryrebuild
ninja 1m15.8 0m0.10m07.3
make1m19.4 0m1.40m07.9
auto3m19.9 0m2.10m13.0
So only the dry run shows a huge speedup (10-20 times
On Fri, Sep 23, 2011 at 10:17 AM, Daniel Dekkers d.dekk...@cthrough.nlwrote:
Hi David,
I'm looking at your iOSNavApp test for iOS.
A few comments as of now:
- universal -
NavApp3 is an iPhone build, if you run it on an iPad (or iPad simulator) it
emulates an iPhone on screen.
I've made
On Mon, Sep 26, 2011 at 7:08 AM, Andrea Galeazzi galea...@korg.it wrote:
I'm currently evaluating a good tool to introduce a continuous integration
model in my workflow. Because I use CMake to manage all my projects, I'd
like to also use CTest/CDash in order to accomplish such task. I start to
On Mon, Sep 26, 2011 at 11:37 AM, Stephen Torri stephen.to...@gmail.comwrote:
I am using CMake to run SWIG to generate C# wrapper files for a
project. While the attached CMakeLists.txt file produces a Visual
Studio solutions that builds the C++ library, C# wrapper library and
C# prototype
On Tue, Sep 27, 2011 at 1:15 PM, Steven Wilson
steven.wesley.wil...@gmail.com wrote:
Using the Xcode generator, the FOLDER property of targets appears to do
nothing. Is this behavior simply a function a Xcode not supporting
groupings of targets or will support be added in 2.8.6?
I will
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, next has been updated
via f091f7647627cdac251a65ea5bb1d582075eb37d (commit)
via
21 matches
Mail list logo
