[cmake-developers] inappropriate use of PATH_SUFFIXES in FindALSA?
First a snippet taken from FindALSA.cmake from cmake-2.8.7: find_path(ALSA_INCLUDE_DIR NAMES asoundlib.h PATH_SUFFIXES alsa DOC "The ALSA (asound) include directory" ) If I understand correctly how find_path and PATH_SUFFIXES work, then it means that if asoundlib.h has a full path of /some/dir/alsa/asoundlib.h, then ALSA_INCLUDE_DIR will get a value of /some/dir/alsa. I perceive this as a problem because typically (always?) the code that uses ALSA includes and not . And thus there would be a mismatch between -I/some/dir/alsa and #include . Of course, it seems that the problem is frequently just masked, especially on GNU/Linux systems, where /some/dir is actually /usr/include and this directory has a magic property of being a system include directory. So alsa/asoundlib.h gets resolved relative to the implicit /usr/include and not to the explicit /usr/include/alsa. On other systems where asoundlib.h may reside in e.g. /usr/local/include/alsa/asoundlib.h a compiler won't be able to find alsa/asoundlib.h because /usr/local/include doesn't have any magic properties. To summarize, if the C code actually includes alsa/asoundlib.h, then wouldn't it be appropriate to use exactly the same path, alsa/asoundlib.h, with find_path like this: find_path(ALSA_INCLUDE_DIR NAMES alsa/asoundlib.h DOC "The ALSA (asound) include directory" ) ? What do you think? Thank you! -- Andriy Gapon -- 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] inappropriate use of PATH_SUFFIXES in FindALSA?
On 2/9/2012 3:17 AM, Andriy Gapon wrote: First a snippet taken from FindALSA.cmake from cmake-2.8.7: find_path(ALSA_INCLUDE_DIR NAMES asoundlib.h PATH_SUFFIXES alsa DOC "The ALSA (asound) include directory" ) It looks like that was added in the original version: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=450c30b5 so it was not a fix for something AFAIK. To summarize, if the C code actually includes alsa/asoundlib.h, then wouldn't it be appropriate to use exactly the same path, alsa/asoundlib.h, with find_path like this: find_path(ALSA_INCLUDE_DIR NAMES alsa/asoundlib.h DOC "The ALSA (asound) include directory" ) I think so. Philip? -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-developers] [CMake 0012951]: The DEFINE variable doesn't expand with VS generators but expands correctly with the nmake one
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=12951 == Reported By:Amine Khaldi Assigned To: == Project:CMake Issue ID: 12951 Category: CMake Reproducibility:always Severity: major Priority: normal Status: new == Date Submitted: 2012-02-09 11:47 EST Last Modified: 2012-02-09 11:47 EST == Summary:The DEFINE variable doesn't expand with VS generators but expands correctly with the nmake one Description: We (ReactOS) set CMAKE_ASM_COMPILE_OBJECT and use , , ...etc. The expands like the rest of those variables when the nmake files generator is used, but doesn't expand when you use the VS generators. This is blocking us from using them because many of our core components contain asm files as source files. == Issue History Date ModifiedUsername FieldChange == 2012-02-09 11:47 Amine Khaldi 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] CodeLite generator
On Thursday 02 February 2012, Jim Goodnow II wrote: > On 2/2/2012 5:35 AM, Brad King wrote: > > On 2/1/2012 5:51 PM, Jim Goodnow II wrote: > >> I am working on a CodeLite generator for CMake. > > > > Great! I assume you mean http://www.codelite.org/ ? > > Yes, the open source IDE. > > > > Is there a set of tests that should be run > > > > CMake comes with an extensive test suite that covers > > the major interfaces plus many corner cases that have > > been encountered and fixed over the years. If you build > > CMake from source with the Makefile generator you can run > > > > bin/ctest > > > > from the top of the build tree to execute all the tests. > > We expect them to all pass for a new generator. They are > > contained in the Tests/ subdirectory. > > Great! Just what I was looking for. > > > Once the feature is working we'd like to have a nightly > > > > build submitted to our testing dashboard: > > http://www.cdash.org/CDash/index.php?project=CMake > > > > to ensure that it keeps working. > > No problem. I need to make a version of CodeLite that runs without the > GUI to be able to run the configuration and ctest. At the moment, I run > -G "Unix Makefiles" and then edit the cache file to change the generator > to CodeLite and then rerun with -G CodeLite to get around the > configuration issues. I've been able to build CMake and Clang with only > a few tweaks. I'll keep you posted and let you know if I have any > questions. There is a ticket for this in the bug tracker, it also has some patches attached, but the author didn't respond anymore: http://public.kitware.com/Bug/view.php?id=9901 Maybe this helps a bit. 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] Topic branches in limbo on the stage?
On Wednesday 08 February 2012, David Cole wrote: > The stage is intended only for topics that are imminently going to be > merged to 'next'... > > The following CMake topic branches have been on the stage for quite some > time without being merged to 'next': > > UseEnabledLanguagesForDirectoryInformationFileIncludePath | master=0 next=0 I forgot to delete that one, done. >qt4-deploy | master=0 next=0 > HandleTargetsInCMakeRequiredLibraries | master=0 next=0 I will continue to work on this one in the next days. > CPackNSIS-fixIgnore-INCLUDE_TOPLEVEL | master=0 next=0 > qt4-deploy-test | master=0 next=0 > findblas-bugs | master=0 next=0 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 branch in stage
On Monday 30 January 2012, Stephen Kelly wrote: > David Cole wrote: > > On Sun, Jan 29, 2012 at 11:44 AM, Stephen Kelly > > > > wrote: > >> David Cole wrote: > >>> OK... nearly complete now. Please review, then reply and tell me if > >>> you object to any of the 7 commits in this topic branch. > >> > >> No objections. They all seem fine. > > > > Great, thanks. > > > >>> Steve, I've > >>> preserved your authorship for most of these commits, but have > >>> significantly re-written some of them. > >> > >> The 3 following 073bc421620e25fef6389b0d8b71cfad8ca79786 (CMake: > >> Eliminate cmMakefile::IncludeDirectories) seem to have been > >> substantially re-written. I'm not sure what is the appropriate way to > >> deal with commits like that, but whatever you choose for the author > >> line is fine. > > > > So I guess the question is: if somebody looks up the author at some > > point in the future and comes asking a question, do you want to be the > > one they go to, or would you rather have them come to me? ;-) If you > > want to send them to me, I'll change the author line, but you > > certainly deserve the credit for getting the ball rolling on this > > topic. > > Ok, let's leave it as-is and I'll take responsibility (blame/credit) :) > > > > >>> - double-check with Alex about the changes in cmake::FindPackage -- > >>> Alex? > > Still pending. Sorry that it took so long, I was really busy the last few weeks. I cloned this repo: git clone https://github.com/dlrdave/CMake.git Both the Eclipse generator and cmake --find-package work fine. Just to make completely sure: the purpose of this target property is *not* that targets linking against a library with this property set should reuse these include dirs, right ? Nevertheless, did you already think about how the interface for such a feature could look like (to make sure it fits with this new target property) ? Maybe something like this ? set_target_properties(... PROPERTIES INCLUDE_DIRECTORIES a/ b/ c/ PUBLIC_BUILD_INCLUDE_DIRECTORIES d/ e/ f/ PUBLIC_INSTALL_INCLUDE_DIRECTORIES g/ h/ i/ ) It would have to be possible to separate between include dirs to be used at build time of the library, and include dirs to be used once the library has been installed (similar to the build and install RPATH) ...just to make sure the syntax for the new INCLUDE_DIRECTORIES property is ok and doesn't make problems later on. 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] FindImageMagick.cmake backwards compatibility
On Monday 30 January 2012, David Cole wrote: ... > From your original post: > > "So when ImageMagick is installed everything behaves as always. But if no > ImageMagick is installed behaviour was this: > > find_package(ImageMagick) -> ImageMagick_FOUND = TRUE" > > This is simply clearly incorrect, and is one of those changes that > deserves to have its backwards compatibility broken. > > If I were a client of this module, and I had logic that really > depended on ImageMagick being found, then it would be broken already > in some other way anyhow. > > I would rather have ImageMagick_FOUND be set correctly than have it be > set "incorrectly but the same as the last version of CMake." Same for me. 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
[cmake-developers] [CMake 0012952]: FindGetText.cmake can create the same target multiple times
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=12952 == Reported By:Alex Neundorf Assigned To:Alex Neundorf == Project:CMake Issue ID: 12952 Category: Modules Reproducibility:always Severity: minor Priority: normal Status: assigned == Date Submitted: 2012-02-09 16:15 EST Last Modified: 2012-02-09 16:15 EST == Summary:FindGetText.cmake can create the same target multiple times Description: FindGetText.cmake uses add_custom_target() to create custom targets, e.g. in the function GETTEXT_PROCESS_PO_FILES(). If this is called multiple times, the target is created multiple times. This works only if CMP0002 is set to OLD. Not doing this would be better. == Issue History Date ModifiedUsername FieldChange == 2012-02-09 16:15 Alex Neundorf New Issue 2012-02-09 16:15 Alex Neundorf Status new => assigned 2012-02-09 16:15 Alex Neundorf Assigned To => Alex Neundorf == -- 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 branch in stage
On 2/9/2012 3:45 PM, Alexander Neundorf wrote: Just to make completely sure: the purpose of this target property is *not* that targets linking against a library with this property set should reuse these include dirs, right ? Correct. It's just to allow the directory-level INCLUDE_DIRECTORIES specification to be target-level. Nevertheless, did you already think about how the interface for such a feature could look like (to make sure it fits with this new target property) ? Maybe something like this ? set_target_properties(... PROPERTIES INCLUDE_DIRECTORIES a/ b/ c/ PUBLIC_BUILD_INCLUDE_DIRECTORIES d/ e/ f/ PUBLIC_INSTALL_INCLUDE_DIRECTORIES g/ h/ i/ ) It would have to be possible to separate between include dirs to be used at build time of the library, and include dirs to be used once the library has been installed (similar to the build and install RPATH) ...just to make sure the syntax for the new INCLUDE_DIRECTORIES property is ok and doesn't make problems later on. I think it could work the same way as linking versus LINK_INTERFACE_LIBRARIES. Anyway, this is not a design goal for the current work and the current work's interface is a natural extension of what is there already. -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 branch in stage
On Thu, Feb 9, 2012 at 3:45 PM, Alexander Neundorf wrote: > On Monday 30 January 2012, Stephen Kelly wrote: > > David Cole wrote: > > > On Sun, Jan 29, 2012 at 11:44 AM, Stephen Kelly > > > > > > wrote: > > >> David Cole wrote: > > >>> OK... nearly complete now. Please review, then reply and tell me if > > >>> you object to any of the 7 commits in this topic branch. > > >> > > >> No objections. They all seem fine. > > > > > > Great, thanks. > > > > > >>> Steve, I've > > >>> preserved your authorship for most of these commits, but have > > >>> significantly re-written some of them. > > >> > > >> The 3 following 073bc421620e25fef6389b0d8b71cfad8ca79786 (CMake: > > >> Eliminate cmMakefile::IncludeDirectories) seem to have been > > >> substantially re-written. I'm not sure what is the appropriate way to > > >> deal with commits like that, but whatever you choose for the author > > >> line is fine. > > > > > > So I guess the question is: if somebody looks up the author at some > > > point in the future and comes asking a question, do you want to be the > > > one they go to, or would you rather have them come to me? ;-) If you > > > want to send them to me, I'll change the author line, but you > > > certainly deserve the credit for getting the ball rolling on this > > > topic. > > > > Ok, let's leave it as-is and I'll take responsibility (blame/credit) :) > > > > > > > > >>> - double-check with Alex about the changes in cmake::FindPackage -- > > >>> Alex? > > > > Still pending. > > Sorry that it took so long, I was really busy the last few weeks. > > I cloned this repo: git clone https://github.com/dlrdave/CMake.git > > Both the Eclipse generator and cmake --find-package work fine. > Excellent : thanks very much for trying it out. I'll try to get this first draft merged to 'next' tonight or tomorrow. > > Just to make completely sure: the purpose of this target property is *not* > that targets linking against a library with this property set should reuse > these include dirs, right ? > > Nevertheless, did you already think about how the interface for such a > feature > could look like (to make sure it fits with this new target property) ? > Maybe something like this ? > set_target_properties(... PROPERTIES > INCLUDE_DIRECTORIES a/ b/ c/ > PUBLIC_BUILD_INCLUDE_DIRECTORIES d/ e/ f/ > PUBLIC_INSTALL_INCLUDE_DIRECTORIES g/ h/ i/ ) > > It would have to be possible to separate between include dirs to be used at > build time of the library, and include dirs to be used once the library has > been installed (similar to the build and install RPATH) > > ...just to make sure the syntax for the new INCLUDE_DIRECTORIES property > is ok > and doesn't make problems later on. > > 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 > -- 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 0012953]: Make sure argument passed to CTest are not modified
The following issue has been SUBMITTED. == http://www.cmake.org/Bug/view.php?id=12953 == Reported By:Jean-Christophe Fillion-Robin Assigned To: == Project:CMake Issue ID: 12953 Category: CTest Reproducibility:have not tried Severity: minor Priority: normal Status: new == Date Submitted: 2012-02-09 18:38 EST Last Modified: 2012-02-09 18:38 EST == Summary:Make sure argument passed to CTest are not modified Description: In the "steps to reproduce", we can read: Reading Script: /home/jchris/Projects/sandbox/foo.cmake,url##http:/cmake.org whereas the following is expected: Reading Script: /home/jchris/Projects/sandbox/foo.cmake,url##http://cmake.org It seems the problem occurs in cmCTestScriptHandler line 186. Calling "CollapseFullPath" on the string "/path/to/ctestscript.cmake,arguments" probably causes the arguments to be modified. See http://cmake.org/gitweb?p=cmake.git;a=blob;f=Source/CTest/cmCTestScriptHandler.cxx;h=5841b8d42bd3873ccdbeaee25349b103bf89eb18;hb=HEAD#l186 Steps to Reproduce: jchris@karakoram:~/Projects/sandbox $ ctest -S foo.cmake,url##http://cmake.org -VV * Extra verbosity turned on Reading Script: /home/jchris/Projects/sandbox/foo.cmake,url##http:/cmake.org CMake Error: Cannot find file: /home/jchris/Projects/sandbox/foo.cmake == Issue History Date ModifiedUsername FieldChange == 2012-02-09 18:38 Jean-Christophe Fillion-RobinNew 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
