[cmake-developers] [CMake 0013883]: add_custom_command associated with PRE_LINK doesn't work as expected when compiling with msbuild.exe from a windows batch
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13883 == Reported By:Dom Ledit Assigned To: == Project:CMake Issue ID: 13883 Category: CMake Reproducibility:always Severity: major Priority: urgent Status: new == Date Submitted: 2013-01-28 08:26 EST Last Modified: 2013-01-28 08:26 EST == Summary:add_custom_command associated with PRE_LINK doesn't work as expected when compiling with msbuild.exe from a windows batch Description: The add_custom_command associated with the PRE_LINK argument miss-behaves if we try to compile/link a Visual Studio 10 solution by calling msbuild.exe from a Windows batch. No issue if we compile/link the solution from the Visual Studio 10 IDE or using the devenv CLI. Steps to Reproduce: See the README.txt file in the attached zip file for instructions to install the source directory tree, to configure the CMake Makefile and build the test_program.exe. More details are also given in the README.txt file == Issue History Date ModifiedUsername FieldChange == 2013-01-28 08:26 Dom Ledit New Issue 2013-01-28 08:26 Dom Ledit File Added: PreLinkEvent.zip == -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0013884]: SONAME_FLAG incorrectly prefixed to libraries in link.txt relink.txt, causes linker to fail
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=13884 == Reported By:Taoki Assigned To: == Project:CMake Issue ID: 13884 Category: CMake Reproducibility:always Severity: major Priority: high Status: new == Date Submitted: 2013-01-28 09:22 EST Last Modified: 2013-01-28 09:22 EST == Summary:SONAME_FLAG incorrectly prefixed to libraries in link.txt relink.txt, causes linker to fail Description: I discovered a major problem while configuring two C++ projects with cmake. When Generating the configuration, cmake adds the word SONAME_FLAG before the name of each library in link.txt and relink.txt once. This causes the linker to fail when compiling with make. Here's the error I get with the OGRE engine: c++: error: SONAME_FLAGlibOgreMain.so.1.9.0: No such file or directory make[2]: *** [lib/libOgreMain.so.1.9.0] Error 1 make[1]: *** [OgreMain/CMakeFiles/OgreMain.dir/all] Error 2 make: *** [all] Error 2 After hours of digging into the issue, I found where it happens and what goes wrong. Here's the OGRE and libOgreMain example, but the problem happens with each library of projects that are affected: - After you generate your cmake configuration, open the file .../OGRE/build/OgreMain/CMakeFiles/OgreMain.dir/link.txt - Somewhere within this file, you will find the following part: -shared SONAME_FLAGlibOgreMain.so.1.9.0 - To fix it, you must manually change that to: -shared -Wl,-soname,libOgreMain.so.1.9.0 Steps to Reproduce: - Get the source of one of the projects affected by the issue. I only noticed it with OGRE and PolyVox, other C++ codes work fine. - Unpack it and run cmake (in my case I use cmake-gui). Specify Unix makefiles with Default native compilers. If the main folder is OGRE set the build folder to OGRE/build. Leave all cmake options to their defaults and Configure then Generate. Normally you should see no errors or warnings. - Now go to OGRE/build and run make. It will start to compile, but when it gets to linking the first library you get the error: c++: error: SONAME_FLAGlibWhatever.so.1.2.3: No such file or directory Additional Information: Experienced with cmake 2.8.8. Operating system is Linux openSUSE 12.2 KDE 4.9.5. == Issue History Date ModifiedUsername FieldChange == 2013-01-28 09:22 Taoki New Issue == -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Adding some generic section to the docs ?
On Jan 27, 2013, at 11:19 AM, Alexander Neundorf neund...@kde.org wrote: On Sunday 27 January 2013, Eric Noulard wrote: 2013/1/27 David Cole dlrd...@aol.com: On Jan 27, 2013, at 6:03 AM, Alexander Neundorf neund...@kde.org wrote: Hi, I'm about to start adding Generic sections to the generated documentation. This could contain * a section about the regeexps supported by cmake, so it doesn't have to be documented in the string() and/or if() command * a section about generator expressions, this appars currently multiple times in the docs * a section about the search order of find_xxx(), which appears currently under find_library(), _file(), _path(), _program() and _package() Comments, objections ? Alex [...] It would be nice to be able to cross reference the generic docs from the multiple places you are thinking of replacing... What's your plan for see over here type links? +1 +1 :-) But I think this is an independent feature. Alex Sure, it's independent, but the lack of that feature is a very strong reason why documentation HAS to be duplicated as things stand. Attacking that problem first, and THEN de-duplicating documentation seems more logical to me. D -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Adding some generic section to the docs ?
On 01/28/2013 10:37 AM, David Cole wrote: Sure, it's independent, but the lack of that feature is a very strong reason why documentation HAS to be duplicated as things stand. Yes. Attacking that problem first, and THEN de-duplicating documentation seems more logical to me. I'd much rather migrate to an existing markup language like reStructuredText than roll our own. It will require additional tools to be installed to build the documentation, but reST is quite readable in source form anyway. We can keep the current generated documentation internal markup syntax and write a document formatter that produces .rst files in order to transition while still allowing existing documentation to work with command-line help output. With this approach we could add new documentation sections just by adding .rst files to the source tree. Optionally we could use something like Sphinx: http://sphinx-doc.org/ to build full documentation from them. -Brad -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Interface includes and defines plumbing
On Wednesday 16 January 2013, Stephen Kelly wrote: Brad King wrote: On 01/08/2013 09:07 AM, Stephen Kelly wrote: Done now, thanks. Currently target_include_directories cannot be used with a RHS target that has not yet been created. This could be problematic for projects that want circular include dependencies, especially with targets in sibling directories. Can the non-target/relative-path argument error be moved to generate time when $TARGET_PROPERTY:INTERFACE_INCLUDE_DIRECTORIES,BadTarget is evaluated? Does this make sense? It is probably possible. Everything in the INCLUDE_DIRECTORIES property should be a relative path if added by include_directories(), and also if the property is populated directly, given http://www.cmake.org/Bug/view.php?id=13188 . You mean should be absolute, right ? So cmTarget::GetIncludeDirectories could probably be taught to cmGeneratorExpression::Split and treat anything non-relative as a target. A Non-absolute, right ? 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Interface includes and defines plumbing
Alexander Neundorf wrote: On Wednesday 16 January 2013, Stephen Kelly wrote: Brad King wrote: On 01/08/2013 09:07 AM, Stephen Kelly wrote: Done now, thanks. Currently target_include_directories cannot be used with a RHS target that has not yet been created. This could be problematic for projects that want circular include dependencies, especially with targets in sibling directories. Can the non-target/relative-path argument error be moved to generate time when $TARGET_PROPERTY:INTERFACE_INCLUDE_DIRECTORIES,BadTarget is evaluated? Does this make sense? It is probably possible. Everything in the INCLUDE_DIRECTORIES property should be a relative path if added by include_directories(), and also if the property is populated directly, given http://www.cmake.org/Bug/view.php?id=13188 . You mean should be absolute, right ? Yes. So cmTarget::GetIncludeDirectories could probably be taught to cmGeneratorExpression::Split and treat anything non-relative as a target. A Non-absolute, right ? Yes. Thanks, Steve. -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] target_include_directories() accepts only absolute paths ?
On Sunday 27 January 2013, Stephen Kelly wrote: Alexander Neundorf wrote: Is there a reason why target_include_directories() should behave differently ? That results from the semantics of the INCLUDE_DIRECTORIES property and http://public.kitware.com/Bug/view.php?id=13188 Ok. This applies to setting the target property directly. But, I think target_include_directories() could still handle relative paths so that CMAKE_CURRENT_SOURCE_DIR is prepended before it is set as a target property. Yes. However code like this would be ambiguous until generate-time: target_include_directories(foo PRIVATE bar) Is bar a target or a directory? That means storing a longer string for bar: Simply saying that an existing directory with the given name has priority over a target with the same name would not be ok ? This would mean that directories shadow targets (or only not-yet-existing targets), while the other way round targets shadow directories. http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5734/focu s=5920 https://gitorious.org/~steveire/cmake/steveires- cmake/commit/6fcdd6e4d47d0469baad228a84ebb9269dceb488 I don't know if that has a big impact but it's an unfortunately long string to have to store for such a small input. We can also allow relative directories in a later release anyway. I'd prefer at this point to be focussed on things which do have to be in this release. Yes. 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] target_include_directories() accepts only absolute paths ?
Alexander Neundorf wrote:
On Sunday 27 January 2013, Stephen Kelly wrote:
Alexander Neundorf wrote:
Is there a reason why
target_include_directories() should behave differently ?
That results from the semantics of the INCLUDE_DIRECTORIES property
and http://public.kitware.com/Bug/view.php?id=13188
Ok.
This applies to setting the target property directly.
But, I think target_include_directories() could still handle relative
paths so that CMAKE_CURRENT_SOURCE_DIR is prepended before it is set as
a target property.
Yes. However code like this would be ambiguous until generate-time:
target_include_directories(foo PRIVATE bar)
Is bar a target or a directory? That means storing a longer string for
bar:
Simply saying that an existing directory with the given name has priority
over a target with the same name would not be ok ?
Currently we do the opposite. First check if 'bar' is a target name, and if
not, then treat it as a directory.
This would mean that directories shadow targets (or only
not-yet-existing targets), while the other way round targets shadow
directories.
As directories should be set up front, that could be a good idea and could
indeed allow us to determine at configure-time if 'bar' is a directory or
might be a target.
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5734/focu
s=5920
https://gitorious.org/~steveire/cmake/steveires-
cmake/commit/6fcdd6e4d47d0469baad228a84ebb9269dceb488
I don't know if that has a big impact but it's an unfortunately long
string to have to store for such a small input.
We can also allow relative directories in a later release anyway. I'd
prefer at this point to be focussed on things which do have to be in this
release.
Yes.
Although if we're going to change from
if (target) {} else if (directory) {}
to
if (directory) {} else if (target) {}
we should do that this release.
I can have a look later/tomorrow depending on whether anything gets merged
today. It would require refactoring which would conflict with my interface-
commands-lazy-target-check branch.
Thanks,
Steve.
--
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] FindPackageCheckArchLinuxSymlinks branch on stage
Alexander Neundorf wrote: On Friday 25 January 2013, Brad King wrote: On 01/25/2013 03:24 PM, Alexander Neundorf wrote: On Friday 25 January 2013, Brad King wrote: On 01/25/2013 05:14 AM, Stephen Kelly wrote: Are INSTALL(EXPORT)ed files affected at all by this? Do they need to be? Yes, since they compute paths relative to their location in order to be relocatable. The code that generates them may need to be made aware of this. I don't think so. These file should be installed into lib/, so even if lib/ is a symlink, the relative path from the targets file to the library does not cross the symlink. What if an executable target installed to bin/ is exported in the targets file? Right. It looks like you merged your patch to next, but didn't account for this part. I recommend doing something similar to what you did for the macro to manipulate the _IMPORT_PREFIX in export files. Wait for my fix-relocatable- include-dirs topic to be merged first though. Thanks, Steve. -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] FindPackageCheckArchLinuxSymlinks branch on stage
On Monday 28 January 2013, Stephen Kelly wrote: Alexander Neundorf wrote: On Friday 25 January 2013, Brad King wrote: On 01/25/2013 03:24 PM, Alexander Neundorf wrote: On Friday 25 January 2013, Brad King wrote: On 01/25/2013 05:14 AM, Stephen Kelly wrote: Are INSTALL(EXPORT)ed files affected at all by this? Do they need to be? Yes, since they compute paths relative to their location in order to be relocatable. The code that generates them may need to be made aware of this. I don't think so. These file should be installed into lib/, so even if lib/ is a symlink, the relative path from the targets file to the library does not cross the symlink. What if an executable target installed to bin/ is exported in the targets file? Right. It looks like you merged your patch to next, but didn't account for this part. I recommend doing something similar to what you did for the macro to manipulate the _IMPORT_PREFIX in export files. Wait for my fix-relocatable- include-dirs topic to be merged first though. I thought that's your part, since you're working on the target stuff a lot :-) 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Setting includes, defines and other usage requirements with one command
On Sunday 27 January 2013, Stephen Kelly wrote:
Alexander Neundorf wrote:
Does
function(target_use_stuff _target )
target_compile_definitions(${_target} ${ARGN})
target_include_directories(${_target} ${ARGN})
target_link_libraries(${_target} ${ARGN})
endfunction()
actually differ from what you want to do for tll() ?
Yes. tll() takes LINK_PUBLIC and the others take PUBLIC for example.
Yes, but this is just a different keyword meaning basically the same.
Additionally tll() can take non-targets such as library-file names and
strings such as -Wl,-Bsymbolic-functions -Wl,-z,relro -lgssapi_krb5 -lkrb5
-lk5crypto -lcom_err as is used in kdelibs (from GSSAPI).
There is some clean-up to do, but it is possible to write a macro for it,
as I wrote here:
Is it maybe a bit inconsistent that
- to setup linking, I can use tll() with targets and with paths
- to setup include dirs, I can use tll() with targets, or tid() with targets
and directories, or id() with directories
Should include_directories() maybe also be taught to recognize targets ?
I mean, it kind of makes sense that tll() does not (will not) handle
directories for setting up include dirs, but I'm still not sure I like that
tll() will handle linking completely and partly setting up the includes.
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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Adding some generic section to the docs ?
2013/1/28 Brad King brad.k...@kitware.com: On 01/28/2013 10:37 AM, David Cole wrote: Sure, it's independent, but the lack of that feature is a very strong reason why documentation HAS to be duplicated as things stand. Yes. Attacking that problem first, and THEN de-duplicating documentation seems more logical to me. I'd much rather migrate to an existing markup language like reStructuredText than roll our own. It will require additional tools to be installed to build the documentation, but reST is quite readable in source form anyway. We can keep the current generated documentation internal markup syntax and write a document formatter that produces .rst files in order to transition while still allowing existing documentation to work with command-line help output. If we transition from current doc format to rst (or may be asciidoc see later on) I'd suggest we keep a way to get command line doc from this new source. My best wish workflow would be to write all docs in relatively powerful but lightweight markup (like rst of asciidoc) and then 1) build-time generate pure ascii doc that can be parsed and spitted-out --help- command line options like we have today. We could parse rst/asciidoc directly but it may bring more dependencies into CMake source which doesn't seem a desirable property to me. 2) generate more beautiful doc (HTML, PDF/TEX/DOCBOOK) with links, references etc... with sphinx or whatever tool we chose. 1] is very important to me because: A) you keep sort of builtin doc with no needed tool B) bash/zsh completion works very well because of the --help--list we have for cmake, cpack, ctest With this approach we could add new documentation sections just by adding .rst files to the source tree. I insist that all structured doc should be accessible from command line without being forced to open a web browser or pdf viewer etc Optionally we could use something like Sphinx: http://sphinx-doc.org/ to build full documentation from them. Sorry no time to go on IRC for some weeks I'll try to catch-up next week. -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] target_include_directories() accepts only absolute paths ?
On 01/28/2013 12:27 PM, Stephen Kelly wrote: Yes. However code like this would be ambiguous until generate-time: target_include_directories(foo PRIVATE bar) Is bar a target or a directory? That means storing a longer string for bar: Simply saying that an existing directory with the given name has priority over a target with the same name would not be ok ? Currently we do the opposite. First check if 'bar' is a target name, and if not, then treat it as a directory. Can we consider using syntax to make this unambiguous? For non-targets we can require at least one slash to subsume full paths and allow relative paths: target_include_directories(foo PRIVATE bar/ ./zot) Perhaps the existence of a non-slash subdirectory could also be enough for a non-target. There is the disadvantage that the case of target_compile_definitions(foo PRIVATE SOME_DEFINE) now expands in the COMPILE_DEFINITIONS property to $$TARGET_DEFINED:SOME_DEFINE:$TARGET_PROPERTY:SOME_DEFINE,INTERFACE_COMPILE_DEFINITIONS;$$NOT:$TARGET_DEFINED:SOME_DEFINE:SOME_DEFINE If SOME_DEFINE is *already* a target then this is not needed. Only out-of-order cases need it. Also we should be able to perform partial evaluation at generate time so that the exported interface does not have this. Users could also write target_compile_definitions(foo PRIVATE bar=) to state that 'bar' is a definition name and not a target. We could also allow/accept a -D in front of definition names and have tcd() strip them out when setting the property. This would also help in cases where variables contain lists meant for the old add_definitions command which wants -D. What's missing is a concise syntax to say that a string *is* a target. One could write $TARGET_PROPERTY:bar,INTERFACE_COMPILE_DEFINITIONS but that exposes the plumbing. Ideas? -Brad -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] target_include_directories() accepts only absolute paths ?
On 01/28/2013 02:30 PM, Brad King wrote: Can we consider using syntax to make this unambiguous? What's missing is a concise syntax to say that a string *is* a target. One could write $TARGET_PROPERTY:bar,INTERFACE_COMPILE_DEFINITIONS but that exposes the plumbing. Ideas? Actually solving this would solve the ambiguity problem by allowing us to require special syntax for referencing targets from tid and tcd. This may also address Alex's concern over in http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/5904/focus=5945 On 01/28/2013 01:05 PM, Alexander Neundorf wrote: Is it maybe a bit inconsistent that - to setup linking, I can use tll() with targets and with paths - to setup include dirs, I can use tll() with targets, or tid() with targets and directories, or id() with directories Should include_directories() maybe also be taught to recognize targets ? I mean, it kind of makes sense that tll() does not (will not) handle directories for setting up include dirs, but I'm still not sure I like that tll() will handle linking completely and partly setting up the includes. What if only tll continues to allow raw target names and tid and tcd assume non-target without using a generator expression? In the common use case tll will now do linking/includes/defines for targets anyway so we will need tid and tcd only for real raw dirs/defs. -Brad -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Setting includes, defines and other usage requirements with one command
On 01/26/2013 06:57 AM, Stephen Kelly wrote: Brad King wrote: How can a package author allow old dependents using the old style to keep working while also allowing new dependents using the new style to work? So, the options I see are: 1) Upstream introduces a find_package-time variable to evaluate whether to populate the INTERFACE_INCLUDE_DIRECTORIES (similar to QT4_USE_IMPORTED_TARGETS). Upstream would likely have to clear the target property in that case after including the exported targets file. This will require new downstreams to explicitly activate the new interface, always :( 2) CMake introduces a standard documented way to not populate the target property in the exported targets file at all (PACKAGE_NAME_NO_INTERFACE_INCLUDE_DIRECTORIES, off by default). How do we know the package name? It would have to be EXPORT_NAME, no? 3) Upstream introduces a new set of IMPORTED targets which have the INTERFACE_INCLUDE_DIRECTORIES set. CMake introduces a way to control at INSTALL(EXPORT) time whether to populate it. So upstream would do this: INSTALL(EXPORT fooTargets NAMESPACE Foo:: ...) INSTALL(EXPORT fooTargets EXPORT_INCLUDE_INTERFACE NAMESPACE FooNew:: ...) I think that will create confusion over the purpose of the two copies. If the upstream were CMake we could add a policy for this. We need to do something similar without a policy in upstream CMake for every project out there. If downstreams were to specify a required version number in their find_package call then the upstream could activate the new interface when the required version is high enough. This does not help when no version is requested though, and that is very common. The upstream could require that a version be requested if the downstream wants the new interfaces to be available, but that does not allow a downstream to optionally work with older versions of the upstream. Perhaps it could work if the upstream provided an explicit variable (option 1 above) that has meaning when the requested version is not present or not new enough. Then downstreams would be able to use the variable to get the new interfaces if the upstream is new enough to provide them but still work with old upstreams. -Brad -- 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://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[CMake] ccmake is not getting installed
Hello, I am trying to install the latest version of cmake on my centos linux machine. [root@83 lib64]# uname -a Linux 83.shin.fluid.cse.nagoya-u.ac.jp 2.6.18-164.el5 #1 SMP Thu Sep 3 03:28:30 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux When I run the bootsrap command, it executes it successfully but gives me the following message at the end: Curses libraries were not found. Curses GUI for CMake will not be built. I need the ccmake command. I checked and I have the libncurses lib file in the /usr/lib and /usr/lib64 folders: --- [root@83 lib]# ls libncurses* libncurses.alibncurses_g.a libncurses.so.5 libncurses++w.a libncursesw_g.a libncursesw.so.5 libncurses++.a libncurses.so libncurses.so.5.5 libncursesw.alibncursesw.so libncursesw.so.5.5 [root@83 lib64]# ls libncurses* libncurses.alibncurses_g.a libncurses.so.5 libncurses++w.a libncursesw_g.a libncursesw.so.5 libncurses++.a libncurses.so libncurses.so.5.5 libncursesw.alibncursesw.so libncursesw.so.5.5 I checked for updates for all the ncurses packages and my yum is telling me it is already up-to-date. (I have shown the output at the end of this email). Please help me. I am not sure where to go about from here. I need ccmake to run to install a software which depends on it. Thanks Pradeep - [root@83 lib64]# yum install ncurses Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * addons: ftp.iij.ad.jp * base: ftp.iij.ad.jp * extras: ftp.iij.ad.jp * updates: ftp.iij.ad.jp Setting up Install Process Package ncurses-5.5-24.20060715.x86_64 already installed and latest version Package ncurses-5.5-24.20060715.i386 already installed and latest version Nothing to do [root@83 lib64]# yum install ncurses-devel Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * addons: ftp.iij.ad.jp * base: ftp.iij.ad.jp * extras: ftp.iij.ad.jp * updates: ftp.iij.ad.jp Setting up Install Process Package ncurses-devel-5.5-24.20060715.x86_64 already installed and latest version Package ncurses-devel-5.5-24.20060715.i386 already installed and latest version Nothing to do -- 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] ccmake is not getting installed
Am Montag, 28. Januar 2013 um 09:15:58, schrieb Pradeep Jha pradeep.kumar@gmail.com When I run the bootsrap command, it executes it successfully but gives me the following message at the end: Curses libraries were not found. Curses GUI for CMake will not be built. To compile, you need the devel-version of libncurses package. On your OS it may have slightly different name. Kornel signature.asc Description: This is a digitally signed message part. -- 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] ccmake is not getting installed
2013/1/28 Kornel Benko kor...@lyx.org: Am Montag, 28. Januar 2013 um 09:15:58, schrieb Pradeep Jha pradeep.kumar@gmail.com When I run the bootsrap command, it executes it successfully but gives me the following message at the end: Curses libraries were not found. Curses GUI for CMake will not be built. To compile, you need the devel-version of libncurses package. On your OS it may have slightly different name. On redhat-like distro (RHEL, Fedora, CentOS, ...) it's usually called packageName-devel, yo could try yum install ncurses-devel -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- 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] adding automatic handling of dependencies for swig-generated modules
Hello all,
swig supports the -MM option which lists a module dependencies (C/C++
headers and other .i interface files). I'd like to use it in order
to let cmake know about these dependencies without user intervention.
In addition to reducing the user burden, that would also help managing
dependencies on files which are outside of the current cmake project.
For instance when a swig module extends another one.
Currently, the user has to list these dependencies in a
SWIG_MODULE_${modulename}_EXTRA_DEPS variable. If a user changes the
.i file to add a #include line, he should also edit the CMakeLists.txt
file to add the corresponding header to the list. Editing the
CMakeLists.txt will cause make to run cmake again, hence the new
dependency will be taken into account.
Apparently, there was an attempt already:
http://public.kitware.com/Bug/view.php?id=4147
Its inner workings are simple:
* first, in swig_add_module, call swig -MM on the interface file, in
order to gather the dependencies,
* then use add_custom_command to generate the wrapper code (call swig
without -MM) whenever a dependency changes.
I see two shortcomings with this implementation (please correct me if I'm wrong)
* swig -MM fails if it cannot find an header, hence it should be
called *after* the headers generation. Because of this problem, the
patch was reverted. I fear the only solution here is to let the user
list these generated dependencies explicitly, and make the swig -MM
call depend on them. We could use the
SWIG_MODULE_${modulename}_EXTRA_DEPS variable for this.
* swig -MM is only called when cmake is run. If the user changes the
interface file to add a %include, make will call swig to generate the
wrappers, but won't call swig -MM again. So the new dependency will go
unnoticed.
This last problem is probably trickier. Maybe we could use a single
add_custom_command, which would
* call swig -MM
* compare the dependencies it gets against its current ones. If the
two sets differ, call cmake,
* call swig to generate the wrappers
But I'm not sure about how to save the current dependencies and
about the conditional call to cmake.
Maybe swig --MM could output to a file, whose (content) change would
trigger cmake?
I'm pretty sure this is a quite common scenario, is there a canonical
solution? Or another module doing the same kind of dependency analysis
where I should look for inspiration?
Regards,
-- Sébastien
--
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] Any portable way in CMake build tree to find Source tree path?
Thanks for all your help. It does seem like you can spend a long time
working with CMake (nearly 10 years for me) and still learn new things!
On Sat, Jan 26, 2013 at 8:48 AM, Cory Quammen cquam...@cs.unc.edu wrote:
Oops, I didn't know about that command. I tried it out, and it works
like a charm.
Thanks for pointing it out, Alex!
Cory
On Sat, Jan 26, 2013 at 3:25 AM, Alexander Neundorf
a.neundorf-w...@gmx.net wrote:
On Saturday 26 January 2013, Cory Quammen wrote:
Kent,
I have a CMake function that may be of interest to you (see attached
file).
For your purposes, use it as follows:
GetCMakeCacheValue( ${ABC_BUILD_DIR} ABC_SOURCE_DIR )
where the project against which you want to build is named ABC.
The first argument must always be the build directory of a project
configured with CMake. The second (and an arbitrary number of
subsequent arguments) are variables whose values you want to retrieve
from the CMakeCache.txt file.
Assuming everything goes well, two new variables will be defined in
the scope in which you called GetCMakeCacheValue:
ABC_SOURCE_DIR
ABC_SOURCE_DIR_TYPE
If there is no entry for ABC_SOURCE_DIR, then the above variables will
take on the values
ABC_SOURCE_DIR-NOT_FOUND
ABC_SOURCE_DIR_TYPE-NOT_FOUND
I hope this is useful to you and others. It would be great if CMake
had similar functionality built in.
Have you tried the load_cache() command ?
According to the documentation it does that, but I haven't used it
myself yet.
Alex
--
Cory Quammen
Research Associate
Department of Computer Science
The University of North Carolina at Chapel Hill
--
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] CPack DEB dependencies
When I try installing a cpack generated .rpm package on another machine, it also installs a handful of other dependent packages (including the 32 bit libc.so.6 for one of the 32 bit executables among all the 64 bit ones). But a cpack generated .deb package isn't that smart. Is there any way to fix this, either in cpack or in my cpack config? At a minimum, I think all I really need is the 32 bit libc.so.6. -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- 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] CPack DEB dependencies
On Monday, January 28, 2013 11:59:46 AM Clinton Stimpson wrote: When I try installing a cpack generated .rpm package on another machine, it also installs a handful of other dependent packages (including the 32 bit libc.so.6 for one of the 32 bit executables among all the 64 bit ones). But a cpack generated .deb package isn't that smart. Is there any way to fix this, either in cpack or in my cpack config? At a minimum, I think all I really need is the 32 bit libc.so.6. I think I found what I'm looking for: set(CPACK_DEBIAN_PACKAGE_SHLIBDEPS ON) -- Clinton Stimpson Elemental Technologies, Inc Computational Simulation Software, LLC www.csimsoft.com -- 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] CPack DEB dependencies
2013/1/28 Clinton Stimpson clin...@elemtech.com: When I try installing a cpack generated .rpm package on another machine, it also installs a handful of other dependent packages (including the 32 bit libc.so.6 for one of the 32 bit executables among all the 64 bit ones). But a cpack generated .deb package isn't that smart. This is because CPackRPM uses rpmbuild which usually have a builtin step for auot-discovering basic dependencies. At least if you build it on the same platform/distro you'll be installing it. Is there any way to fix this, either in cpack or in my cpack config? You can try to set CPACK_DEBIAN_PACKAGE_SHLIBDEPS to ON. Read the doc to see why it is not on by default: cpack --help-variable CPACK_DEBIAN_PACKAGE_SHLIBDEPS At a minimum, I think all I really need is the 32 bit libc.so.6. You can always craft dependencies by hand: cpack --help-variable CPACK_DEBIAN_PACKAGE_DEPENDS -- Erk Le gouvernement représentatif n'est pas la démocratie -- http://www.le-message.org -- 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] CPack DEB dependencies
On Monday, January 28, 2013 10:07:04 PM Eric Noulard wrote:
2013/1/28 Clinton Stimpson clin...@elemtech.com:
When I try installing a cpack generated .rpm package on another machine,
it
also installs a handful of other dependent packages (including the 32 bit
libc.so.6 for one of the 32 bit executables among all the 64 bit ones).
But a cpack generated .deb package isn't that smart.
This is because CPackRPM uses rpmbuild which usually have a builtin step
for auot-discovering basic dependencies. At least if you build it on the
same platform/distro you'll be installing it.
Is there any way to fix
this, either in cpack or in my cpack config?
You can try to set CPACK_DEBIAN_PACKAGE_SHLIBDEPS to ON.
Read the doc to see why it is not on by default:
cpack --help-variable CPACK_DEBIAN_PACKAGE_SHLIBDEPS
There is a typo in that help. It has the word toi
Ok, I'm running into that probably of not finding dependencies within my own
package. In the package, there are some 3rd party plugins without rpaths
(these plugins don't need them), but it complains about not finding dependent
libraries.
Do you know if there is some what to give it the path?
I'm hoping for something like this in my cpack config (which doesn't work):
set(ENV{LD_LIBRARY_PATH} $ENV{DESTDIR}/${CMAKE_INSTALL_PREFIX}/lib)
I'm curious why rpmbuild didn't have this problem, do you know?
And why would automatic dependencies be ON by default for RPM but not for DEB?
--
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com
--
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] ccmake is not getting installed
Eric Noulard eric.noulard@... writes: 2013/1/28 Kornel Benko kornel@...: Am Montag, 28. Januar 2013 um 09:15:58, schrieb Pradeep Jha pradeep.kumar.jha@... When I run the bootsrap command, it executes it successfully but gives me the following message at the end: Curses libraries were not found. Curses GUI for CMake will not be built. To compile, you need the devel-version of libncurses package. On your OS it may have slightly different name. On redhat-like distro (RHEL, Fedora, CentOS, ...) it's usually called packageName-devel, yo could try yum install ncurses-devel Hello, thank you for your replies. I mentioned in previous email that I tried this command already and this is what I am getting as output: - [root@83 ~]# yum install ncurses-devel Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * addons: ftp.iij.ad.jp * base: ftp.iij.ad.jp * extras: ftp.iij.ad.jp * updates: ftp.iij.ad.jp Setting up Install Process Package ncurses-devel-5.5-24.20060715.x86_64 already installed and latest version Package ncurses-devel-5.5-24.20060715.i386 already installed and latest version Nothing to do - It says that the ncurses is already installed on the system. Any other leads? Regards, Pradeep -- 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
