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.e...@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.e...@controlsdata.com > <javascript:_e(%7B%7D,'cvml','anthony.r.e...@controlsdata.com');> > > > > *From:* Parag Chandra [mailto:pa...@ionicsecurity.com > <javascript:_e(%7B%7D,'cvml','pa...@ionicsecurity.com');>] > *Sent:* Tuesday, August 18, 2015 3:08 PM > *To:* Ette, Anthony (CDS); CMake@cmake.org > <javascript:_e(%7B%7D,'cvml','CMake@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.e...@controlsdata.com > <javascript:_e(%7B%7D,'cvml','anthony.r.e...@controlsdata.com');>> > *Date: *Tuesday, August 18, 2015 at 2:59 PM > *To: *Parag Chandra <pa...@ionicsecurity.com > <javascript:_e(%7B%7D,'cvml','pa...@ionicsecurity.com');>>, " > CMake@cmake.org <javascript:_e(%7B%7D,'cvml','CMake@cmake.org');>" < > CMake@cmake.org <javascript:_e(%7B%7D,'cvml','CMake@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.e...@controlsdata.com > <javascript:_e(%7B%7D,'cvml','anthony.r.e...@controlsdata.com');> > > > > *From:* Parag Chandra [mailto:pa...@ionicsecurity.com > <javascript:_e(%7B%7D,'cvml','pa...@ionicsecurity.com');>] > *Sent:* Tuesday, August 18, 2015 2:45 PM > *To:* Ette, Anthony (CDS); CMake@cmake.org > <javascript:_e(%7B%7D,'cvml','CMake@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.e...@controlsdata.com > <javascript:_e(%7B%7D,'cvml','anthony.r.e...@controlsdata.com');>> > *Date: *Tuesday, August 18, 2015 at 2:29 PM > *To: *"CMake@cmake.org <javascript:_e(%7B%7D,'cvml','CMake@cmake.org');>" > <CMake@cmake.org <javascript:_e(%7B%7D,'cvml','CMake@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.e...@controlsdata.com > <javascript:_e(%7B%7D,'cvml','anthony.r.e...@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. >
-- 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