[CMake] Imported libraries and cross platform target names

[David Cole]

Find_library results are cached. If you want to re-find a potentially moved
library every time you run, you would have to unset the cache variable
prior to finding it.

D


On Thursday, August 20, 2015, Ette, Anthony (CDS) <
Anthony.R.Ette at controlsdata.com> wrote:

> Ok so I’ve got this going now (kind of) but FIND_LIBRARY doesn’t seem to
> update when the specified PATH changes.  Since we are developing and
> releasing our own static libraries on a separate development cycle from the
> final applications, a final application may use a different library release
> than another.  This means the application developer needs a method to point
> to different library releases (different locations on the filesystem).
> We’ve always used environment variables for this and the developer issues a
> “workon” prior to developing an application.  The workon sets up all the
> necessary env vars but FIND_LIBRARY doesn’t update when the env var does.
> For example, using either method 1 or 2 below to set an internal cmake
> variable doesn’t do the trick for the FIND_LIBRARY command to pick up a new
> libtest file in the new location.
>
>
>
>
>
> 1)      FILE(TO_CMAKE_PATH $ENV{LIB_DIR} LIB_D)
>
> 2)      SET(LIB_D $ENV{LIB_DIR} CACHE STRING "lib dir" FORCE)
>
>
>
> FIND_LIBRARY(libtest     NAMES test     PATHS {LIB_D} NO_DEFAULT_PATH)
>
>
>
>
>
>
>
> I’ve also tried using the env string directly in the FIND_LIBRARY command
> as below, but the library being used in the build tree Makefiles still does
> not get updated.  I’ve also confirmed that the env var *is*  updated when
> CMake is rerun using MESSAGE command, so I believe it is merely a problem
> with triggering a change to the FIND_LIBRARY command.  How does this
> triggering work?  How can I force FIND_LIBRARY to check again each time
> CMake runs?
>
>
>
> FIND_LIBRARY(libtest     NAMES test     PATHS $ENV{LIB_DIR}
> NO_DEFAULT_PATH)
>
>
>
>
>
> Thanks,
>
>
> *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
> <javascript:_e(%7B%7D,'cvml','Anthony.R.Ette at controlsdata.com');>
>
>
>
> *From:* Parag Chandra [mailto:parag at ionicsecurity.com
> <javascript:_e(%7B%7D,'cvml','parag at ionicsecurity.com');>]
> *Sent:* Tuesday, August 18, 2015 3:08 PM
> *To:* Ette, Anthony (CDS); CMake at cmake.org
> <javascript:_e(%7B%7D,'cvml','CMake at cmake.org');>
> *Subject:* Re: [CMake] Imported libraries and cross platform target names
>
>
>
> Yes, very similar. When I set out to convert our existing build system,
> which consists of many individual .sln and .vcxproj files, I got a
> requirement that the developers do not all want to work out of the same
> “uber” Xcode workspace/VS solution that contains all of the projects. They
> want to continue working with solutions that contain only the library of
> interest plus its associated test project. So when a developer runs CMake,
> a dependency like “timer” may refer to another CMake-generated project
> within the current build system, or it may refer to an
> already-built/downloaded dependency of the same name.
>
>
> *Parag Chandra*
> Senior Software Engineer, Mobile Team
> Mobile: +1.919.824.1410
>
> <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
> <javascript:_e(%7B%7D,'cvml','Anthony.R.Ette at controlsdata.com');>>
> *Date: *Tuesday, August 18, 2015 at 2:59 PM
> *To: *Parag Chandra <parag at ionicsecurity.com
> <javascript:_e(%7B%7D,'cvml','parag at ionicsecurity.com');>>, "
> CMake at cmake.org <javascript:_e(%7B%7D,'cvml','CMake at cmake.org');>" <
> CMake at cmake.org <javascript:_e(%7B%7D,'cvml','CMake at cmake.org');>>
> *Subject: *RE: [CMake] Imported libraries and cross platform target names
>
>
>
> 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
> <javascript:_e(%7B%7D,'cvml','Anthony.R.Ette at controlsdata.com');>
>
>
>
> *From:* Parag Chandra [mailto:parag at ionicsecurity.com
> <javascript:_e(%7B%7D,'cvml','parag at ionicsecurity.com');>]
> *Sent:* Tuesday, August 18, 2015 2:45 PM
> *To:* Ette, Anthony (CDS); CMake at cmake.org
> <javascript:_e(%7B%7D,'cvml','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://ionic.com>
>
> Ionic Security Inc.
> 1170 Peachtree St. NE STE 400, Atlanta, GA 30309
>
>
>
> *From: *<Ette>, "Anthony (CDS)" <Anthony.R.Ette at controlsdata.com
> <javascript:_e(%7B%7D,'cvml','Anthony.R.Ette at controlsdata.com');>>
> *Date: *Tuesday, August 18, 2015 at 2:29 PM
> *To: *"CMake at cmake.org <javascript:_e(%7B%7D,'cvml','CMake at cmake.org');>"
> <CMake at cmake.org <javascript:_e(%7B%7D,'cvml','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(TARGETtestPROPERTYIMPORTED_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
> <javascript:_e(%7B%7D,'cvml','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.
>
>
> ______________________________________________________________________
> 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/20150821/7ea341c9/attachment-0001.html>