[CMake] Imported libraries and cross platform target names
Ette, Anthony (CDS)
Anthony.R.Ette at controlsdata.com
Tue Aug 18 14:59:11 EDT 2015
Thank you, I will take a look at find_library. The static libraries are ones we build in-house but in a separate CMake-generated build system. The reason we use a separate build system is because our common library code is used by all applications and, as such, is on a separate development cycle than the applications themselves. In other words, while there may be advantages to combining them, I don’t think it would really make sense in our case….any thoughts? Are you in a similar situation?
Anthony Ette
Control Systems Engineer
Rolls-Royce Controls and Data Services
7661 N Perimeter Rd
Indianapolis, IN 46241
tel: +1 (317) 230-6943
mob: +1 (317) 864-7975
email: Anthony.R.Ette at controlsdata.com<mailto:Anthony.R.Ette at controlsdata.com>
From: Parag Chandra [mailto:parag at ionicsecurity.com]
Sent: Tuesday, August 18, 2015 2:45 PM
To: Ette, Anthony (CDS); CMake at cmake.org
Subject: Re: [CMake] Imported libraries and cross platform target names
You just specify the “basename” of the library, so something like this:
find_library (timer NAMES timer PATHS your/library/directory)
target_link_libraries(test timer)
And Cmake takes care of the rest. It’s even easier if “timer” is also part of the same CMake-generated build system. In that case, the find_library isn’t even needed.
Things do get a little more complicated when you want to distinguish between release/debug variants of the same library. For that you can use the DEBUG and OPTIMIZED keywords of target_link_libraries().
Parag Chandra
Senior Software Engineer, Mobile Team
Mobile: +1.919.824.1410
[https://www.ionicsecurity.com/IonicSigHz.png]<https://ionic.com>
Ionic Security Inc.
1170 Peachtree St. NE STE 400, Atlanta, GA 30309
From: <Ette>, "Anthony (CDS)" <Anthony.R.Ette at controlsdata.com<mailto:Anthony.R.Ette at controlsdata.com>>
Date: Tuesday, August 18, 2015 at 2:29 PM
To: "CMake at cmake.org<mailto:CMake at cmake.org>" <CMake at cmake.org<mailto:CMake at cmake.org>>
Subject: [CMake] Imported libraries and cross platform target names
Given that add_library() produces a unique filename per platform (the “actual file name of the library built is constructed based on conventions of the native platform (such as lib<name>.a or<name>.lib”), how does one add the library to the final application without having to deal with the filename difference? In other words, I’ve got one library that, by default, produces ‘libtest.a’ on Linux and ‘test.lib’ on Windows. How can I add this imported library into the final application in a cross platform manner? I know I can specify two different imported locations (see below), but it seems odd to me that Cmake – the cross-platform build env generator – doesn’t have a better native way of dealing with this….
The snippet below will work, but just seems wrong given the nature of what CMake is intended to do…is there a better way that I’m missing?! If not, can I request that a future release of Cmake handle platform naming convention difference internally when invoking ADD_LIBRARY with the IMPORTED tag set? Ok so, to be fair, Cmake can be used to cross compile and that certainly complicates my feature request but, when not cross compiling, CMake knows what platform it’s being executed on so it should be able to resolve static archive platform decorations internally.
ADD_LIBRARY(testSTATICIMPORTED)
if(WIN32)
SET_PROPERTY(TARGETtestPROPERTYIMPORTED_LOCATION ${LIB_D}/timer.lib)
endif()
if(UNIX)
SET_PROPERTY(TARGETtest PROPERTYIMPORTED_LOCATION ${LIB_D}/libtimer.a)
endif()
Thanks in advance,
Anthony Ette
Control Systems Engineer
Rolls-Royce Controls and Data Services
7661 N Perimeter Rd
Indianapolis, IN 46241
tel: +1 (317) 230-6943
mob: +1 (317) 864-7975
email: Anthony.R.Ette at controlsdata.com<mailto:Anthony.R.Ette at controlsdata.com>
This e-mail (including attachments) contains contents owned by Rolls-Royce plc and its subsidiaries, affiliated companies or customers and covered by the laws of England and Wales, Brazil, US, or Canada (federal, state or provincial). The information contained in this email is intended to be confidential, may be legally privileged and subject to export controls which may restrict the access to and transfer of the information. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, interception or copying of this communication is strictly prohibited and may subject you to further legal action. Reply to the sender if you received this email by accident, and then delete the email and any attachments.
______________________________________________________________________
This email has been scanned.
This e-mail (including attachments) contains contents owned by Rolls-Royce plc and its subsidiaries, affiliated companies or customers and covered by the laws of England and Wales, Brazil, US, or Canada (federal, state or provincial). The information contained in this email is intended to be confidential, may be legally privileged and subject to export controls which may restrict the access to and transfer of the information. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, interception or copying of this communication is strictly prohibited and may subject you to further legal action. Reply to the sender if you received this email by accident, and then delete the email and any attachments.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake/attachments/20150818/2db18a36/attachment-0001.html>
More information about the CMake
mailing list