[CMake] Imported libraries and cross platform target names

Thu Aug 20 20:06:37 EDT 2015

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<mailto:Anthony.R.Ette at controlsdata.com>

From: Parag Chandra [mailto:parag at ionicsecurity.com]
Sent: Tuesday, August 18, 2015 3:08 PM
To: Ette, Anthony (CDS); 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://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:59 PM
To: Parag Chandra <parag at ionicsecurity.com<mailto:parag at ionicsecurity.com>>, "CMake at cmake.org<mailto:CMake at cmake.org>" <CMake at cmake.org<mailto: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<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<mailto: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(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<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.

______________________________________________________________________
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/ffd02730/attachment-0001.html>