Re: [CMake] Eclipse generator - scanner-discovered include pathsand pre-processor symbols
Hi,
On Tuesday 29 March 2011, Chatterjee, Shash wrote:
> Hi Alex,
>
> Thanks for the change. The version you sent didn't end up working here
> (with just a CXX project). The line to set the compiler is checking for
> "CXX" but, at least on my system, "${_lang}" is set to "c++". Once I
> changed the line to check for "CXX" or "c++", it worked fine. I also
> noticed that /usr/include was not being added, and it was because the
> regexp was skipping the last line of includes. I have modified the regexp
> slightly, and that worked as well. I have attached the changed file for
> you to compare, I am not sure if the changes are just specific to my
> system.
thanks, merged and pushed to next. This should be in 2.8.5.
Alex
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] INSTALL(EXPORT) does not honor LINK_INTERFACE_LIBRARIES?
On 04/02/2011 10:52 AM, Rolf Eike Beer wrote:
> Am Donnerstag, 31. März 2011, 15:26:31 schrieb Brad King:
>> On 03/31/2011 09:14 AM, Rolf Eike Beer wrote:
>>> See below. Looks like the only way to prevent this is to set
>>> LINK_INTERFACE_LIBRARIES to empty for every lib that uses the static
>>> lib.
>>> Which may be a good idea anyway as that transitive linking is harmful.
>>
>> CMake has always done said transitive linking for historical reasons.
>> The default behavior cannot change now. It is not necessarily harmful
>> if the static library objects are built with -fPIC and are not all
>> absorbed into the shared library that initially links it.
>
> set(DONT_DO_SILLY_LEGACY_OVERLINKING true)? ;)
>
>> The documented way to turn off transitive linking is to set the
>> LINK_INTERFACE_LIBRARIES property. Once that is done then install(EXPORT)
>> will not complain about the transitive static libraries anymore. However,
>> it *will* complain about the *shared* libraries for the reason I explained
>> in my earlier response to this thread.
>
> I start to get the point ;)
>
>> On 03/29/2011 05:36 PM, Rolf Eike Beer wrote:
>>> Am Dienstag, 29. März 2011, 09:41:36 schrieb Brad King:
CMake running in an outside application needs to know these private
runtime dependencies. It needs them ensure that the application link
line is generated such that the linker can find the transitive
dependencies (e.g. -rpath-link) of the public library.
>>>
>>> No, why should it?
>>
>> See the sample script below. CMake needs to know where bar's transitive
>> dependencies are installed so that it can pass the right thing to
>> -rpath-link. This is is how IMPORTED_LINK_DEPENDENT_LIBRARIES is used and
>> why the install(EXPORT) command needs all the targets in the export.
>>
>> Since one target can be installed to multiple locations, or accidentally
>> not at all, the install(TARGETS) for 'foo' must list the same EXPORT as
>> the install(TARGETS) for 'bar' so that CMake can associate the right copy
>> of the dependency.
>
> Isn't the rpath stored inside those shared libraries? So every shared library
> (and the executable itself) know where it's own dependencies are located?
Sometimes, there are good reasons to not set the RPATH tag in the
resulting binaries, and as a default, CMake indeed doesn't do this
during the installation. Look at the following CMakeLists.txt file:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P1 C)
FILE(WRITE ${CMAKE_BINARY_DIR}/private.c
"void private(void){}\n")
ADD_LIBRARY(private SHARED private.c)
FILE(WRITE ${CMAKE_BINARY_DIR}/public.c
"void public(void){private();}\n")
ADD_LIBRARY(public SHARED public.c)
TARGET_LINK_LIBRARIES(public private)
SET_TARGET_PROPERTIES(public PROPERTIES LINK_INTERFACE_LIBRARIES "")
INSTALL(TARGETS public EXPORT p1 LIBRARY DESTINATION lib)
INSTALL(TARGETS private EXPORT p1 LIBRARY DESTINATION lib/p1)
INSTALL(EXPORT p1 DESTINATION share)
Configure, build and install it, e.g. with CMAKE_INSTALL_PREFIX set to
/dev/shm/usr. It's allowed and quite common to have a project's private
libraries in ${CMAKE_INSTALL_PREFIX}/lib/${PROJECT_NAME} instead of the
usual library directory ${CMAKE_INSTALL_PREFIX}/lib, even if the project
is installed to /usr[/local]. Now, look at the following CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(P2 C)
SET(CMAKE_VERBOSE_MAKEFILE ON)
INCLUDE(p1)
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c
"int main(void){public();return 0;}\n")
ADD_EXECUTABLE(main main.c)
TARGET_LINK_LIBRARIES(main public)
INSTALL(TARGETS main RUNTIME DESTINATION bin)
Configure it with CMAKE_MODULE_PATH set to /dev/shm/usr/share, e.g., to
have it find p1.cmake, and build: Everything should work perfectly. Now,
edit /dev/shm/usr/share/p1-noconfig.cmake and remove the line with the
public target's IMPORTED_LINK_DEPENDENT_LIBRARIES_NOCONFIG property,
rebuild and... undefined reference to `private'.
What happens here: You removed the sole information that libpublic.so
depends on libprivate.so, so not only it does not appear in the link
line - that's desired to prevent an explicit dependency of main - but
also its directory does not appear either, and this makes ld fail to
resolve the 'private' symbol. The IMPORTED_LINK_DEPENDENT_LIBRARIES
property's job is exactly to provide that information in case of the
transitive linking being disabled for a shared library, or in other
words: If you disable transitive linking for libpublic.so and do not
set the RPATH tag either, you do need the information conveyed by the
IMPORTED_LINK_DEPENDENT_LIBRARIES property to make the linker succeed
in resolving libprivate.so's symbols, even if they are just indirectly
referred to via libpublic.so. BTW, how would you address this issue on
platforms that do not have a concept like ELF's RPATH tags, e.g. W...?
> Ok, at the end that actually makes sense. But since I'm installing every
> library to the same directory on Un*x wouldn't it be
Re: [CMake] Failures on Nightly CMake Dashboard
The machine cmake.org was offline. It is back up now. On Sat, Apr 2, 2011 at 10:41 PM, Richard Wackerbarth wrote: > All of my Nightly runs of the CMake Dashboard are failing to update with > > > > Determine Nightly Start Time > Specified time: 1:00:00 UTC > Use Nightly tag: 20110403-0100 > Starting fresh build... > Updating the repository: > /usr/home/dashboard/Dashboards/Chameleon-01/CMake/Nightly/CMake > Use GIT repository type > Old revision of repository is: 08e888d6095375d92da36eb6345bd193ee496a58 > New revision of repository is: 08e888d6095375d92da36eb6345bd193ee496a58 > Gathering version information (one . per revision): > > Update command failed: "/usr/local/bin/git" "pull" > Found 0 changed files > Configure project > > And from the Dashboard, it appears that everyone else is having the same > experience. > > > > ___ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake > ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
[CMake] Failures on Nightly CMake Dashboard
All of my Nightly runs of the CMake Dashboard are failing to update with Determine Nightly Start Time Specified time: 1:00:00 UTC Use Nightly tag: 20110403-0100 Starting fresh build... Updating the repository: /usr/home/dashboard/Dashboards/Chameleon-01/CMake/Nightly/CMake Use GIT repository type Old revision of repository is: 08e888d6095375d92da36eb6345bd193ee496a58 New revision of repository is: 08e888d6095375d92da36eb6345bd193ee496a58 Gathering version information (one . per revision): Update command failed: "/usr/local/bin/git" "pull" Found 0 changed files Configure project And from the Dashboard, it appears that everyone else is having the same experience. ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Exclude source files from build for a specific configuration with Visual Studio
On 04/01/2011 03:02 PM, Gaylord Charles wrote:
> Hello,
>
> I am migrating a project from Visual Studio 8 to CMake and I look for a way
> to exclude files from build for a defined configuration.
>
> I think the "HEADER_FILE_ONLY" source file property can suit my needs and it
> would be great to have a "HEADER_FILE_ONLY_ version.
>
> But maybe there is a "workaround" that enables to get this kind of behavior.
>
> Thanks,
> Gaylord CHARLES
AFAIK, you can not prevent the concerned files from being compiled, but
you can prevent their object files from being incorporated in the final
binaries. Admittedly, the method I could offer is somewhat weird:
First of all, isolate the concerned files in a static library; linking
against such a one is quite the same as incorporating the object files
immediately. If desired, a shared library is alright, too. Further on,
you need an intermediate empty static library as an imported target
since imported targets can have arbitrary *configuration-specific*
dependencies. Look at the following CMakeLists.txt:
CMAKE_MINIMUM_REQUIRED(VERSION 2.8 FATAL_ERROR)
PROJECT(CONFIGEXCLUDE C)
FILE(WRITE ${CMAKE_BINARY_DIR}/f.c "void f(void){}\n")
ADD_LIBRARY(f STATIC f.c)
ADD_LIBRARY(helper STATIC "")
SET_TARGET_PROPERTIES(helper PROPERTIES LINKER_LANGUAGE "C")
EXPORT(TARGETS helper NAMESPACE "reimp_"
FILE ${CMAKE_BINARY_DIR}/helper.cmake)
INCLUDE(${CMAKE_BINARY_DIR}/helper.cmake)
SET_TARGET_PROPERTIES(reimp_helper PROPERTIES
IMPORTED_LINK_INTERFACE_LIBRARIES "f"
IMPORTED_LINK_INTERFACE_LIBRARIES_CUSTOM "")
FILE(WRITE ${CMAKE_BINARY_DIR}/main.c "int main(void){return 0;}\n")
ADD_EXECUTABLE(main main.c)
TARGET_LINK_LIBRARIES(main reimp_helper)
ADD_DEPENDENCIES(main f helper)
Target "f" comprises the files to exclude for a specific configuration.
Target "helper" is the intermediate empty static library; it gets re-
imported to the project to set its IMPORTED_LINK_INTERFACE_LIBRARIES
property - to "f" generically and to "" for the "CUSTOM" configuration.
Finally, target "main" is linked against the re-imported helper target.
On *nix, I can see "main" being linked against libf.a unless the build
type in CMAKE_BUILD_TYPE is set to "custom", and I suppose it'll work
in Visual Studio, too. Note that you need to establish the dependency
of main on f and the helper explicitly by ADD_DEPENDENCIES() because
TARGET_LINK_LIBARIES() can't do this anymore.
'hope that helps.
Regards,
Michael
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
[CMake] Dependencies scanning for non-c/c++ files
I have some m4 files in my build that include other m4 files, so there's a dependency between m4 files that can change at any time. I can calculate the dependency at configure time, but what can I do when the files change and I need to recalculate the dependencies? This is obviously handled for c/c++ files by CMake. Any ideas? --- Aaron Wright ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
