Re: [cmake-developers] An option to set LINK_INTERFACE_LIBRARIES to empty on all shared library targets?
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 about what is in the LINK_INTERFACE. I was considering patching CMake to do that by setting an option. http://thread.gmane.org/gmane.comp.kde.devel.buildsystem/6622/focus=72 030 Would such a feature of making set(CMAKE_SET_LINK_INTERFACE_EMPTY ON) cause the LINK_INTERFACE to be empty for all shared library targets be accepted into CMake? I personally am all into this, as this basically makes the same as the linker does when it gets passed --no-copy-dt-needed-entries --as-needed. I would call it a bit different to make more clear what this is all about, something like CMAKE_NO_LINK_IMPLICIT_DEPENDENCIES. 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 don't think I understand your description of the tricky part or your suggested solution. Can you expand on it? What I once tried to do was: build a bunch of libraries (both shared and static), link in some ways, and then export just one shared library that had the link dependencies set to empty. CMake didn't let me, it always wanted to have me export all the other stuff, too. Eike -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] An option to set LINK_INTERFACE_LIBRARIES to empty on all shared library targets?
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 don't think I understand your description of the tricky part or your suggested solution. Can you expand on it? What I once tried to do was: build a bunch of libraries (both shared and static), link in some ways, and then export just one shared library that had the link dependencies set to empty. CMake didn't let me, it always wanted to have me export all the other stuff, too. When you talk about exports you're talking about install(foo EXPORTS ...) right? And when you say CMake didn't let you, do you mean that the installed lib/cmake/foo/fooTargets-debug.cmake contains IMPORTED_LINK_INTERFACE_LIBRARIES_DEBUG Bar;Baz though it shouldn't contain Baz? What did you do to make it not contain Baz, assuming I've restated your issue correctly? Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] An option to set LINK_INTERFACE_LIBRARIES to empty on all shared library targets?
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 _any_ dependencies of a shared library to be exported then. I don't think I understand your description of the tricky part or your suggested solution. Can you expand on it? What I once tried to do was: build a bunch of libraries (both shared and static), link in some ways, and then export just one shared library that had the link dependencies set to empty. CMake didn't let me, it always wanted to have me export all the other stuff, too. When you talk about exports you're talking about install(foo EXPORTS ...) right? Yes. And when you say CMake didn't let you, do you mean that the installed lib/cmake/foo/fooTargets-debug.cmake contains IMPORTED_LINK_INTERFACE_LIBRARIES_DEBUG Bar;Baz though it shouldn't contain Baz? What did you do to make it not contain Baz, assuming I've restated your issue correctly? Nope, it gave me a CMake error when trying to make an export for Bar because it depends on Baz and Baz wasn't exported. At the end I just exported everything for our local build stuff and didn't pass any of these files to users that could have used them, but provided a Find*.cmake for them. Eike -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] An option to set LINK_INTERFACE_LIBRARIES to empty on all shared library targets?
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 better: to not enforce
_any_
dependencies of a shared library to be exported then.
I don't think I understand your description of the tricky part or your
suggested solution. Can you expand on it?
What I once tried to do was: build a bunch of libraries (both shared
and static), link in some ways, and then export just one shared library
that had the link dependencies set to empty. CMake didn't let me, it
always wanted to have me export all the other stuff, too.
When you talk about exports you're talking about install(foo EXPORTS ...)
right?
Yes.
And when you say CMake didn't let you, do you mean that the installed
lib/cmake/foo/fooTargets-debug.cmake
contains
IMPORTED_LINK_INTERFACE_LIBRARIES_DEBUG Bar;Baz
though it shouldn't contain Baz? What did you do to make it not contain
Baz, assuming I've restated your issue correctly?
Nope, it gave me a CMake error when trying to make an export for Bar
because it depends on Baz and Baz wasn't exported.
At the end I just exported everything for our local build stuff and didn't
pass any of these files to users that could have used them, but provided a
Find*.cmake for them.
That sounds like 'just' a bug, right? I can't see how that relates to using
set(CMAKE_LINK_INTERFACE_LIBRARIES )
instead of
macro(wrapper_add_library)
add_library(${ARGN})
target_link_libraries(${ARG1} LINK_INTERFACE_LIBRARIES )
endmacro()
Then again, I haven't understood your issue, because what I understand from
your issue would make almost the entire exports stuff not work, so clearly I
have not understood your issue.
It looks like it should either be a bug report or a documented limitation
though.
All the best,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Setting the link interface and dependencies in one command
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}
${QT_QTGUI_LIBRARIES}
${QT_QTNETWORK_LIBRARIES}
)
target_link_libraries(radiobuttonmodel
LINK_INTERFACE_LIBRARIES
${QT_QTCORE_LIBRARIES}
${QT_QTGUI_LIBRARIES}
)
cmTargetLinkLibrariesCommand.cxx seems to intentionally allow making
libraries part of the link interface without actually linking to them, so we
can't change the behaviour of
target_link_libraries(radiobuttonmodel
${QT_QTNETWORK_LIBRARIES}
LINK_INTERFACE_LIBRARIES
${QT_QTCORE_LIBRARIES}
${QT_QTGUI_LIBRARIES}
)
to be the equivalent of the above. However, we could do something like this:
target_link_libraries(radiobuttonmodel
${QT_QTNETWORK_LIBRARIES}
LINK_INTERFACE
${QT_QTCORE_LIBRARIES}
${QT_QTGUI_LIBRARIES}
)
to be able to specify the link dependencies and the link interface (which
are also dependencies) in one command.
Would that be acceptable to cmake?
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
I'm going to say wait until Brad replies here, but I do not see a
problem with that, *if* it's actually necessary. (Other than the
obvious problem, which is that LINK_INTERFACE and
LINK_INTERFACE_LIBRARIES are very close to each other and people will
get them confused, and constantly be looking at the documentation to
try to figure out which is which... A distinguishing naming
difference, if you could come up with one, would be better. i.e.,
names where you can tell what the meaning is for each, without
referring to the documentation...)
I guess I don't fully understand what you're doing here. If the
libraries are necessary as actual dependencies, then why do they also
have to be in the link interface libraries list...? I thought that
list was just to indicate that you need the libraries, but that things
that link to your library do not need them. If they are actual, hard
dependencies, then how could things that link to your library *not*
need them, too?
David
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Setting the link interface and dependencies in one command
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 agaonst are in the LINK_INTERFACE, which leads to unnecessary dependencies and increased load time. The alternative would be not to set it to empty, and expect our developers to take care of it. I think this is not realistic. So I'm quite sure we still want that David Cole wrote: I'm going to say wait until Brad replies here, but I do not see a problem with that, *if* it's actually necessary. (Other than the obvious problem, which is that LINK_INTERFACE and LINK_INTERFACE_LIBRARIES are very close to each other and people will get them confused, and constantly be looking at the documentation to try to figure out which is which... A distinguishing naming difference, if you could come up with one, would be better. i.e., names where you can tell what the meaning is for each, without referring to the documentation...) set_target_libraries(foo bar baz LINK_DEPENDENCY_LIBRARIES bat mar ) So bat and mar do not become part of the link interface libraries? This is analogous to the IMPORTED_LINK_DEPENDENCY_LIBRARIES I think. I guess I don't fully understand what you're doing here. If the libraries are necessary as actual dependencies, then why do they also have to be in the link interface libraries list...? I thought that list was just to indicate that you need the libraries, but that things that link to your library do not need them. Actually, I think the opposite is true. Things in the link interface libraries list are not actually linked against. By putting things in the link interface libraries list you indicate that things that use your library also need to link against the things in the link interface libraries list. If they are actual, hard dependencies, then how could things that link to your library *not* need them, too? Is this still an issue, given the above? Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Reworking SystemInformation
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 changes to KWSys files. This makes accepting patches for it a bit more work for us than a simple git am -3 -- the real KWSys files are still in a shared CVS repository, and we mirror them into our git repo through a robot. So... we have to apply your patch to the CVS repo, and wait for the mirror to replay them into the CMake git repo. Furthermore, you cannot simply analyze CMake and say that some KWSys functionality is definitively unused -- KWSys is shared among many, many projects, (including VTK, ITK, gccxml, ParaView, and others...) any of which may actually be using something in it that you propose to remove. Personally, I hate much of the code that is in SystemInformation.cxx, and I try to avoid using it or relying on it for anything critically cross-platform. As you've observed, there are several holes in it that are in need of plugging to make it robust and useful/use-able... Looks like your patch was based on some other commit that is not in 'master' ...? I get this when I try to apply it: davidcole@HUT11 ~/Dashboards/My Tests/CMake (sysinfo-rework) $ git am -3 ~/Downloads/0001-remove-trailing-whitespace.patch Applying: remove trailing whitespace fatal: sha1 information is lacking or useless (Source/kwsys/SystemInformation.cxx). Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. Patch failed at 0001 remove trailing whitespace When you have resolved this problem run git am --resolved. If you would prefer to skip this patch, instead run git am --skip. To restore the original branch and stop patching run git am --abort. I'm willing to remove things that are truly unused, and cluttering up the interface. But first we have to be absolutely sure they are unused across all KWSys clients. And I'm more inclined to add to the interface to return a string for a CPU identifier than to *change* the existing interface. I'd rather leave well enough alone as much as possible in KWSys, and add new stuff that is fully cross-platform as needed moving forward. HTH, David On Sat, Nov 6, 2010 at 3:31 PM, Rolf Eike Beer e...@sf-mail.de wrote: I wanted to have a look if I could fix one of my bugs (0010895: Processor detection is very x86-specific). What I found was some things in kwsys classes I'm not sure about. First there is a bunch of files that have trailing whitespaces over and over which seems rather randomly scattered over the files. I did for i in *; do sed 's/[ \t]*$//' -i $i; done which lead to the attached patch (0001). Next I found a thing called testSystemInformation.cxx. Looks like it is a program to debug the SystemInformation class. It is the only user of some things like DoesCPUSupportCPUID(), GetProcessorAPICID(), and DoesCPUSupportFeature() from that class. What about just kicking them out? AFAICT this is Windows-only stuff so this is pretty useless on nearly all architectures anyway. I just deleted some of them and it still compiles without problems so I don't see any problems (patch 0002). The next thing is the root cause of the above bug: nearly everything in that class is centered around Intel like CPUs. While that is indeed the majority of the platforms that use CMake (at least in numbers of users) this makes support for other CPUs a bit harder. E.g. storing the processor family as integer makes sense on x86 as it's encoded this way there but what /proc/cpuinfo on my C3600 prints as family id is PA-RISC 2.0 which doesn't fit in an integer at all. I would like to rework that so the transition from integer to string is done immediately on query and the string is stored also on x86 so non-x86 would work without any further action at least on Linux. Comments? Eike -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] branch HandleCMAKE_CXX_COMPILER_ARG1InEclipse for 2.8.6 ?
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 Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] branch HandleCMAKE_CXX_COMPILER_ARG1InEclipse for 2.8.6 ?
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 affects an awfully small percentage of the total CMake user base... So we may not take it. But, since it's so small, we may. Thx, David On Sat, Oct 1, 2011 at 1:32 PM, Alexander Neundorf neund...@kde.org wrote: 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 Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] branch HandleCMAKE_CXX_COMPILER_ARG1InEclipse for 2.8.6 ?
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 build 2.8.6 on Monday. You must admit, this fix affects an awfully small percentage of the total CMake user base... So we may not take it. But, since it's so small, we may. That's what I thought too :-) Alex -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] branch HandleCMAKE_CXX_COMPILER_ARG1InEclipse for 2.8.6 ?
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 build the final 2.8.6. If we take no changes, I'll build 2.8.6 on Monday. You must admit, this fix affects an awfully small percentage of the total CMake user base... So we may not take it. But, since it's so small, we may. That's what I thought too :-) How many last minute changes to accept appears to be a universal issue for releasing software. I have turned more and more conservative on this issue as I gained experience with the downsides of such changes for other projects. For me it now boils down to these questions: 1. If there is a high upside (many users benefit) to the last-minute change, then why aren't you delaying the release to make sure the change is properly tested? 2. If there is a low upside to the last-minute change (only a few users benefit), can you bet your project's reputation that there is no downside for all users or would it be better to wait for the next release cycle to gain more testing of the change? CMake developers will obviously have to make up their own mind on this issue for their releases, but as you can tell from the way those questions are posed, I almost always discourage last-minute changes in releases for projects where I am one of the developers. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Setting the link interface and dependencies in one command
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 have to be linked against foo. This saves startup time and other things. Packagers also like that. No, you got something wrong here. Packagers hate that. That's exactly the reason why e.g. Fedora and others introduced -Wl,no-unneeded (or how that's called) in their default linker flags. If your hello needs foo and bar, and is only linked to bar because that one is already linked against foo, that your package will not work any longer if you replace foo 1.0 with foo 1.1 which is totally binary compatible but doesn't need foo internally any longer because your hello then misses symbols on startup. This is called unterlinking of hello and should be avoided whereever possible. The opposite is overlinking and that was what I tried to avoid: my hello did not need any symbols from foo itself, so I wanted to get rid of them (which worked by forcing the implicit dependencies to empty). But CMake still did not want to allow me to export the bar target without also exporting foo even if the linkage to foo was only an internal detail and the user was not even allowed to use foo directly. Eike -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Setting the link interface and dependencies in one command
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, and my executable hello links against bar, it doesn't also
have to be linked against foo. This saves startup time and other things.
Packagers also like that.
No, you got something wrong here. Packagers hate that. That's exactly the
reason why e.g. Fedora and others introduced -Wl,no-unneeded (or how that's
called) in their default linker flags.
If your hello needs foo and bar, and is only linked to bar because that one
is already linked against foo, that your package will not work any longer if
you replace foo 1.0 with foo 1.1 which is totally binary compatible but
doesn't need foo internally any longer because your hello then misses symbols
on startup. This is called unterlinking of hello and should be avoided
whereever possible.
The opposite is overlinking and that was what I tried to avoid: my hello did
not need any symbols from foo itself, so I wanted to get rid of them (which
worked by forcing the implicit dependencies to empty). But CMake still did
not want to allow me to export the bar target without also exporting foo even
if the linkage to foo was only an internal detail and the user was not even
allowed to use foo directly.
Can you consider this example as a demonstration for why cmake wants
information about foo in the exports file even though its an internal detail?
project(test)
set(CMAKE_SKIP_RPATH 1)
add_library(foo SHARED test.cpp)
set_target_properties(foo PROPERTIES LIBRARY_OUTPUT_DIRECTORY foo)
add_library(bar SHARED test.cpp)
target_link_libraries(bar foo)
set_target_properties(bar PROPERTIES LIBRARY_OUTPUT_DIRECTORY bar
LINK_INTERFACE_LIBRARIES )
add_executable(baz test.cpp)
# 1) link giving target name
#target_link_libraries(baz bar)
# 2) link giving the path to the library
target_link_libraries(baz ${CMAKE_CURRENT_BINARY_DIR}/bar/libbar.so)
If I do #2, I get a link warning
/usr/bin/ld: warning: libfoo.so, needed by bar/libbar.so, not found (try using
-rpath or -rpath-link)
If I do #1, then I don't get that warning and if I turn on verbose output, I
see that cmake wasn't linking foo into baz anyway. Apparently the linker wants
to have a look at dependent shared libraries, and cmake is using the
-rpath-link flag for that.
This information is passed into the exports file, and cmake needs the dependent
shared libraries for that.
Clint
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
