FindIce module and C++11

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

FindIce module and C++11

Jones J.W.

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.

 

Would it be possible to add a flag to tell the FindIce module whether C++11 is being used or not?

 

Thanks,

 

Jason

 

-

Dr Jason W Jones

Associate Professor

College of Engineering

Swansea University

Singleton Park

Swansea

UK

SA2 8PP

Tel: +44-1792-295869

 


--

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FindIce module and C++11

Roger Leigh
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.
>
> 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.


Kind regards,
Roger Leigh

--

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FindIce module and C++11

Roger Leigh
On 2017-08-10 10:28, [hidden email] 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FindIce module and C++11

Rolf Eike Beer
In reply to this post by Roger Leigh
Am Donnerstag, 10. August 2017, 10:28:31 schrieb [hidden email]:

> 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.
> >
> > 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.
To me this smells like an imported target with a generator expression that
uses the C++11 or other lib depending on the used interface of the target. No
idea if that is possible, but that would be the direction I would search in.

Greetings,

Eike
--

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

signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: FindIce module and C++11

Roger Leigh
On 11/08/17 20:15, Rolf Eike Beer wrote:

> Am Donnerstag, 10. August 2017, 10:28:31 schrieb [hidden email]:
>> 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.
>>>
>>> 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.
>
> To me this smells like an imported target with a generator expression that
> uses the C++11 or other lib depending on the used interface of the target. No
> idea if that is possible, but that would be the direction I would search in.

I'm unsure, but I suspect it's not appropriate.  I'm currently treating
them as separate libraries because whether C++11 is used by the compiler
is orthogonal to whether you're using the C++11 Ice API (and code
generator).  Ice generates language-specific interfaces and
implementations from abstract definitions, and it treats C++ and C++11
as essentially different languages.  You need to explicitly opt into
using C++11 in the interface definitions for code generation, and with
respect to which libraries you link to.

For anyone using Ice who would like to test, I've opened
   https://gitlab.kitware.com/cmake/cmake/merge_requests/1137for testing
and review.  Would be helpful if anyone wanting to use Ice 3.7 could
give it a try, but equally if you're using 3.[3456] it would be great to
know if there are any regressions.  I'll be testing Ice 3.5, but no
longer have any of the others lying around (3.3 can probably be removed,
it's so old and unsupported).


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
Loading...