On 2017-08-10 10:28, rle...@codelibre.net wrote:
On 2017-08-10 09:50, Jones J.W. wrote:
I'm building my code on Linux using the g++ flags "-std=c++11". This
means that I must link with the libIce++11 libraries instead of
libIce.
The FindIce module, however as no provision for choosing these
libraries thus resulting in unresolved symbols at link time.
I tried getting around the problem by simply listing Ice++11 as a
COMPONENT which works in Linux but the same CMakeLists.txt file in
Windows won't work as there is no Ice++11. Currently I have resolved
this by having two calls to the FindIce module inside an IF( MSVC )
conditional.
Looking at the NuGet packages, I can see Ice++11 on Windows; it's named
Ice37++11[d].lib. Helpfully not following the existing conventions on
the other platforms and previous Ice releases, but I think I've worked
around this now.
Would it be possible to add a flag to tell the FindIce module whether
C++11 is being used or not?
FindIce certainly needs an update for Ice 3.7.
Regarding C++11, their approach here is certainly a bit unorthodox as
well as being inconsistent between platforms, and FindIce will need to
deal with that unfortunate situation. Since the old and new APIs are
incompatible, and you have to explicitly opt-in to using the new one,
I don't think that using "-std=c++11" on its own is sufficient reason
to select the C++11 library? Can you use the old API with a C++11
compiler? It might be best to have a set of C++11 component names,
and map these to the appropriate library names on Linux (separate
libs) and Windows (not separate), if that would make the intent of the
user clear and unambiguous.
I will try to look at this, but I'm a little busy with other things at
the moment, and so it's not at top of my list. If you wanted to
propose a change an/or open a merge request that would certainly be
welcome.
I have done some preliminary work here:
https://gitlab.kitware.com/rleigh/cmake/commits/ice-3.7.0
It's working on Linux, but not yet finding the libraries on Windows when
using the NuGet distribution of the libraries. This is likely some
minor bug which I need to identify; it's using all the correct paths and
suffixes that I can see.
If you would like to give this a go and help fix the detection on
Windows, that would be really helpful. I've left some extra debugging
messages in to trace how find_library is working. If you set
CMAKE_PREFIX_PATH to the location where the NuGet packages live, it
should automatically detect the package name. Do we have any existing
conventions within CMake for finding libraries within such packages?
Should the package be listed specifically on CMAKE_PREFIX_PATH, or is
finding the package itself on the path acceptable? Or should both be
supported?
Regards,
Roger
--
Powered by www.kitware.com
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Kitware offers various services to support the CMake community. For more
information on each offering, please visit:
CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake
