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,
13 matches
Mail list logo
