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