[cmake-developers] [CMake 0011731]: Issue with CheckTypeSize test
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=11731 == Reported By:Johannes Brunen Assigned To: == Project:CMake Issue ID: 11731 Category: CMake Reproducibility:N/A Severity: major Priority: low Status: new == Date Submitted: 2011-01-20 04:40 EST Last Modified: 2011-01-20 04:40 EST == Summary:Issue with CheckTypeSize test Description: Hello, after switching from CMake version 2.8.0 to 2.8.3 I ran into the following issue. I have a script named 'FindComLibs1.0.cmake' which does contain the following statement: include(CheckTypeSize) check_type_size(void* _comlibs1.0_void_ptr_size BUILTIN_TYPES_ONLY) running a CMake project containing a find_package call to this script does produce the following error: -- Check size of void* CMake Error: Unknown extension .0_void_ptr_size.c for file E:/prod_xxx_/Build32/caddy/CMakeFiles/CheckTypeSize/_comlibs1.0_void_ptr_size.c. TRY_COMPILE only works for enabled languages. Currently enabled languages are: C CXX RC See PROJECT command for help enabling other languages. -- Check size of void* - failed I think that the determination of the file extension is wrongly implemented. == Issue History Date ModifiedUsername FieldChange == 2011-01-20 04:40 Johannes BrunenNew Issue == ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] On Mac OS X, the CMake .app filename should not contain the version number ( http://public.kitware.com/Bug/view.php?id=11693#c24958 )
On 20 January 2011 15:52, David Cole david.c...@kitware.com wrote: Moving to the CMake developer's list, as requested by this bug comment: http://public.kitware.com/Bug/view.php?id=11693#c24958 Comments or thoughts on the topic are welcome... I'd agree, OSX applications almost never have the version number in the filename. In addition, other CMake things that aren't particularly native: - Using bin/ directories inside Program Files on Windows is a bit weird - I think that CMake shouldn't use version numbers in the Start Menu/folder/executable name on Windows -- Mike McQuaid http://mikemcquaid.com ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] On Mac OS X, the CMake .app filename should not contain the version number ( http://public.kitware.com/Bug/view.php?id=11693#c24958 )
2011/1/20 David Cole david.c...@kitware.com: Moving to the CMake developer's list, as requested by this bug comment: http://public.kitware.com/Bug/view.php?id=11693#c24958 Comments or thoughts on the topic are welcome... Please reply here with any further discussion before adding more info to the bug report. Once a consensus is reached here, we'll update the bug again. I'm not a Mac user and I'm a poor Windows user :-] Now on linux (or other unices) I was puzzled by the /usr/share/cmake-2.8 thing in fact the vast majority unix software don't come with such version mangling. FHS doesn't seems to include recommandation in this area: http://www.pathname.com/fhs/. Sometimes the version mangling appears when a major update (python2 -- python3) arrives and one needs to have both versions installed for compatibility reason. In this case, most of the time, the up-to-date version is unnumbered and the old compatibility one is renamed with version mangling. In fact before the big old-new update thing the new version may be mangled for a while waiting for wider acceptance (Python case). Some libs do always have name mangling because the version is really part of their name., e.g. glib-2.0. Then update-alternative (Debian, Fedora, ?others?) may be used to create appropriate links: http://www.debian-administration.org/articles/91 So I vote for no version mangling. Or may be an option (default to OFF==no mangling) in order to ease the mangling of cmake-2.8 when cmake 3.0 will be out :-] -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.org ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0011734]: Regression from 2.8.3 : add_test in subdir incorrectly keeps cwd at top level CMAKE_BINARY_DIR
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=11734
==
Reported By:David Cole
Assigned To:
==
Project:CMake
Issue ID: 11734
Category: CTest
Reproducibility:always
Severity: major
Priority: high
Status: new
Target Version: CMake 2.8.4
==
Date Submitted: 2011-01-20 13:31 EST
Last Modified: 2011-01-20 13:31 EST
==
Summary:Regression from 2.8.3 : add_test in subdir
incorrectly keeps cwd at top level CMAKE_BINARY_DIR
Description:
The code in the Steps to Reproduce section, after running:
cmake
cmake --build . --config Debug
ctest -C Debug
...produces files ending in .args.txt as follows:
dir /s /b *.args.txt
C:\...\echoargs-test0.args.txt
C:\...\echoargs-test1.args.txt
C:\...\echoargs-test3.args.txt
C:\...\sub\echoargs-test2.args.txt
Actual:
echoargs-test3.args.txt is in the top level directory
Expected:
The file echoargs-test3.args.txt should be in the sub subdir... Just like
the corresponding file for test2.
Apparently, only the NAME/COMMAND signature of add_test is affected by this bug.
Thanks to Andy Bauer for the bug report.
I reproduced this using the attached code on Windows 7 with Visual Studio 2010.
Andy originally discovered this on a Linux box.
Steps to Reproduce:
# top level CMakeLists.txt
cmake_minimum_required(VERSION 2.8)
project(SmallAndFast)
include(CTest)
add_definitions(-D_CRT_SECURE_NO_WARNINGS)
add_executable(echoargs echoargs.c)
add_test(test0 echoargs test0)
add_test(NAME test1 COMMAND echoargs test1 1 $CONFIGURATION)
add_subdirectory(sub)
# subdir sub/CMakeLists.txt
add_executable(echoargsSub ../echoargs.c)
add_test(test2 echoargsSub test2 1 2)
add_test(NAME test3 COMMAND echoargsSub test3 1 2 3 $CONFIGURATION)
// top level echoargs.c
#include direct.h
#include stdio.h
int main(int argc, const char* argv[])
{
int i = 0;
FILE *fp = (FILE *) 0;
char buf[4096];
char filename[256];
const char *cwd = _getcwd(buf, 4095);
const char *name = argc1 ? argv[1] : unknown;
for (; iargc; ++i)
{
fprintf(stdout, %s\n, argv[i]);
}
if (cwd != NULL)
{
fprintf(stdout, cwd='%s'\n, cwd);
}
// When this test is over, there should be an echoargs.txt left in the
// current working directory (the one that was current when the test was
// run...)
sprintf(filename, echoargs-%s.args.txt, name);
fp = fopen(filename, w);
if (NULL != fp)
{
i = 0;
for (; iargc; ++i)
{
fprintf(fp, %s\n, argv[i]);
}
if (cwd != NULL)
{
fprintf(fp, cwd='%s'\n, cwd);
}
fclose(fp);
}
return 0;
}
==
Issue History
Date ModifiedUsername FieldChange
==
2011-01-20 13:31 David Cole New Issue
==
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] On Mac OS X, the CMake .app filename should not contain the version number ( http://public.kitware.com/Bug/view.php?id=11693#c24958 )
On Thu, Jan 20, 2011 at 1:11 PM, Clinton Stimpson clin...@elemtech.com wrote: On Thursday, January 20, 2011 09:36:13 am Eric Noulard wrote: 2011/1/20 David Cole david.c...@kitware.com: Moving to the CMake developer's list, as requested by this bug comment: http://public.kitware.com/Bug/view.php?id=11693#c24958 Comments or thoughts on the topic are welcome... Please reply here with any further discussion before adding more info to the bug report. Once a consensus is reached here, we'll update the bug again. I'm not a Mac user and I'm a poor Windows user :-] Now on linux (or other unices) I was puzzled by the /usr/share/cmake-2.8 thing in fact the vast majority unix software don't come with such version mangling. FHS doesn't seems to include recommandation in this area: http://www.pathname.com/fhs/. Sometimes the version mangling appears when a major update (python2 -- python3) arrives and one needs to have both versions installed for compatibility reason. In this case, most of the time, the up-to-date version is unnumbered and the old compatibility one is renamed with version mangling. In fact before the big old-new update thing the new version may be mangled for a while waiting for wider acceptance (Python case). Some libs do always have name mangling because the version is really part of their name., e.g. glib-2.0. Then update-alternative (Debian, Fedora, ?others?) may be used to create appropriate links: http://www.debian-administration.org/articles/91 So I vote for no version mangling. Or may be an option (default to OFF==no mangling) in order to ease the mangling of cmake-2.8 when cmake 3.0 will be out :-] I also vote for no version number, but allow the user to change it if they want. It seems that would give the general user a more clear upgrade path. I vote for no version number. It is pretty irritating having to recreate my build trees when I upgrade CMake, and it does not seem to fit into the normal pattern used on the Mac. I also noticed the /usr/share/cmake-2.8, and without a /usr/bin/cmake-2.8 I am not sure it makes sense on Linux distros - two CMake's could not coexist in the same prefix as the main binary would collide. Marcus ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0011735]: Generators create empty archives using component groups
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=11735 == Reported By:Torsten Rohlfing Assigned To: == Project:CMake Issue ID: 11735 Category: CPack Reproducibility:always Severity: major Priority: high Status: new == Date Submitted: 2011-01-20 14:52 EST Last Modified: 2011-01-20 14:52 EST == Summary:Generators create empty archives using component groups Description: Packaging of component groups seems to be completely broken in CMake 2.8.3: generated packages are empty. The problem seems to be that CPack installs all files in a single file system tree, regardless of what component they belong to, but then expects to package them from per-component trees. Steps to Reproduce: 1. Download attached file, source.tar.gz 2. tar -xzvf source.tar.gz 3. mkdir build ; cd build; cmake .. 4. make package Afterwards, running find _CPack_Packages/ will produce something like the following: _CPack_Packages/ _CPack_Packages//Darwin _CPack_Packages//Darwin/TGZ _CPack_Packages//Darwin/TGZ/SomeToolkit _CPack_Packages//Darwin/TGZ/SomeToolkit/documentation _CPack_Packages//Darwin/TGZ/SomeToolkit/documentation/usr _CPack_Packages//Darwin/TGZ/SomeToolkit/documentation/usr/local _CPack_Packages//Darwin/TGZ/SomeToolkit/headers _CPack_Packages//Darwin/TGZ/SomeToolkit/headers/usr _CPack_Packages//Darwin/TGZ/SomeToolkit/headers/usr/local _CPack_Packages//Darwin/TGZ/SomeToolkit/libraries _CPack_Packages//Darwin/TGZ/SomeToolkit/libraries/usr _CPack_Packages//Darwin/TGZ/SomeToolkit/libraries/usr/local _CPack_Packages//Darwin/TGZ/SomeToolkit/usr _CPack_Packages//Darwin/TGZ/SomeToolkit/usr/local _CPack_Packages//Darwin/TGZ/SomeToolkit/usr/local/doc _CPack_Packages//Darwin/TGZ/SomeToolkit/usr/local/doc/SOMEFILE _CPack_Packages//Darwin/TGZ/SomeToolkit/usr/local/include _CPack_Packages//Darwin/TGZ/SomeToolkit/usr/local/include/header.h _CPack_Packages//Darwin/TGZ/SomeToolkit-development.tar.gz _CPack_Packages//Darwin/TGZ/SomeToolkit-runtime.tar.gz Clearly, the two package files are both installed below _CPack_Packages//Darwin/TGZ/SomeToolkit/usr/local/ but the package archives are created from _CPack_Packages//Darwin/TGZ/SomeToolkit/documentation _CPack_Packages//Darwin/TGZ/SomeToolkit/headers _CPack_Packages//Darwin/TGZ/SomeToolkit/libraries which are empty. Additional Information: I have observed essentially the same behaviour using PackageMaker generator on Mac and ZIP on Windows. == Issue History Date ModifiedUsername FieldChange == 2011-01-20 14:52 Torsten RohlfingNew Issue 2011-01-20 14:52 Torsten RohlfingFile Added: source.tar.gz == ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0011736]: SOURCES for add_custom_target() are not added to CodeBlocks, Eclipse and KDevelop projects
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=11736
==
Reported By:Alex Neundorf
Assigned To:Alex Neundorf
==
Project:CMake
Issue ID: 11736
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: assigned
==
Date Submitted: 2011-01-20 14:58 EST
Last Modified: 2011-01-20 14:58 EST
==
Summary:SOURCES for add_custom_target() are not added to
CodeBlocks, Eclipse and KDevelop projects
Description:
From the mailing list:
On Thu, Jan 20, 2011 at 7:27 PM, Alexander Neundorf
On Thursday 20 January 2011, Dimitri Kaparis wrote:
Greetings,
the Code Blocks generator is not adding to the project the sources,
specified in the command.
In order to add a group of header files to my project tree, I'm trying
to implement the solution posted here:
http://www.cmake.org/pipermail/cmake/2010-November/040537.html
The target itself is added to the Code Blocks project, however the
source files are not.
Should I file a bug report? Are there any other workarounds for that
use case, besides adding the headers to some other existing executable
or library target?
This is under linux, with CMake release 2.8.3.
add_custom_target() does not have a list of source files. Which behaviour do
you expect ?
Can you post a small example CMakeLists.txt and explain what you would
expect ?
From the documentation at
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:add_custom_target
:
The SOURCES option specifies additional source files to be included
in the custom target. Specified source files will be added to IDE
project files for convenience in editing even if they have not build
rules.
What I'm trying to do is explained in the thread I linked to above. I
have a directory with some utility header files used by several
targets in my project. I want these headers to appear in the list of
sources in Code Block's generated project. So I add a custom target,
listing them as sources:
set(SRCS point.hpp
box.hpp)
add_custom_target(GeometryHeaders SOURCES ${SRCS})
In Code Blocks, however, the header files do not appear in the project
source tree.
I just tried with the MSVC10 generator, and there this adds a project
with the sources listed.
Thanks,
Dimitri
==
Issue History
Date ModifiedUsername FieldChange
==
2011-01-20 14:58 Alex Neundorf New Issue
2011-01-20 14:58 Alex Neundorf Status new = assigned
2011-01-20 14:58 Alex Neundorf Assigned To = Alex Neundorf
==
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[CMake] pb with cmake and intel fortran 11.1
Hello, I meet some problems to run cmake with intel fortran 11.1 + visual 2008 under windows XP 64 bits. I can compile a fortran project under visual, but cmake is not able to detect ifort (I run cmake from the visual dos console). The log of a cmake run is joined to this mail. I wanted to open the test visual solution generated by cmake, but I was not able to find a solution in my build directory ... Cheers, YC -- Building for: Visual Studio 9 2008 -- Check for working C compiler using: Visual Studio 9 2008 -- Check for working C compiler using: Visual Studio 9 2008 -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler using: Visual Studio 9 2008 -- Check for working CXX compiler using: Visual Studio 9 2008 -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Check for working Fortran compiler using: Visual Studio 9 2008 -- Check for working Fortran compiler using: Visual Studio 9 2008 -- broken CMake Error at C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/CMakeTestFortranCompiler.cmake:40 (MESSAGE): The Fortran compiler C:/Program Files (x86)/Intel/ComposerXE-2011/bin/ia32/ifort.exe is not able to compile a simple test program. It fails with the following output: Change Dir: E:/Sources/Arpack/Codes/Arc3D_Rep/trunk/build/CMakeFiles/CMakeTmp Run Build Command:c:\PROGRA~2\MICROS~1.0\Common7\IDE\devenv.com CMAKE_TRY_COMPILE.sln /build Debug /project cmTryCompileExec Microsoft (R) Visual Studio Version 9.0.21022.8. Copyright (C) Microsoft Corp. Tous droits réservés. Impossible de charger un ou plusieurs projets de la solution pour la ou les raisons suivantesÿ: L'application du projet n'est pas installe. Ces projets seront tiquets comme tant non disponibles dans l'Explorateur de solutions. Dveloppez le noeud de projet afin de dterminer la raison pour laquelle le projet n'a pas pu tre charg. Projet non valide Utilisationÿ: devenv [fichiersolution | fichierprojet | unfichier.ext] [commutateurs] Le premier argument de devenv est gnralement un fichier solution ou un fichier projet. Vous pouvez galement utiliser tout autre fichier projet en tant que premier argument si vous souhaitez que le fichier s'ouvre automatiquement dans un diteur. Lorsque vous entrez un fichier projet, l'IDE recherche dans le rpertoire parent du fichier projet un fichier .sln ayant le mme nom de base que le fichier projet. Si aucun fichier .sln n'existe, l'interface IDE recherche un fichier .sln unique qui fait rfrence au projet. Si un tel fichier .sln n'existe pas, l'interface IDE cre une solution non enregistre avec un nom de fichier par dfaut .sln avec le mme nom de base que le fichier projet. Gnrations partir de la ligne de commandeÿ: devenv fichiersolution.sln /build [ configurationsolution ] [ /project fichierounomprojet [ /projectconfig nom ] ] Commutateurs de ligne de commande disponiblesÿ: /BuildCre la solution ou le projet avec la configuration de solution spcifie. Par exemple, Dbogage. Si plusieurs plateformes sont possibles, le nom de la configuration doit tre insr entre guillemets et doit contenir le nom de la plateforme. Par exempleÿ: Dbogage|Win32. /CleanSupprime les sorties de la gnration. /Command Dmarre l'IDE et excute la commande. /Deploy Cre puis dploie la configuration de gnration spcifie. /Edit Ouvre les fichiers spcifis dans une instance en cours d'excution de cette application. S'il n'y a aucune instance en cours d'excution, une nouvelle instance est dmarre avec une disposition de fentre simplifie. /LCID Dfinit la langue par dfaut de l'IDE pour l'interface utilisateur. /Log Enregistre l'activit de l'interface IDE dans le fichier spcifi pour la rsolution des problmes. /NoVSIP Dsactive la cl de licence VSPI du dveloppeur pour les tests VSIP. /Out Ajoute le journal de gnration un fichier spcifi. /Project Spcifie le projet crer, nettoyer ou dployer. Doit tre utilis avec /Build, /Rebuild, /Clean ou /Deploy. /ProjectConfigRemplace la configuration de projet spcifie dans la configuration de la solution. Par exemple Dbogage. Si plusieurs plateformes sont possibles, le nom de la configuration doit tre insr entre guillemets et doit contenir le nom de la plateforme. Par exempleÿ: Dbogage|Win32. Doit tre utilis avec /Project. /Rebuild Nettoie puis cre la solution ou le projet avec la
Re: [CMake] Support for subexpressions in regular expressions?
Thanks for your help to make CMake better, How many CMake commands can work with subexpressions in regular expressions? Are any extensions needed in this application area? Regards, Markus ___ 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] How to assign data from subexpressions of regular expressions to CMake variables?
Thanks for your help to make CMake better, Is the command variant string(REGEX REPLACE ...) completely documented? Can multiple variables be specified that will receive the data from the evaluation of subexpressions in the passed regular expression? Regards, Markus ___ 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 bundle on osx
Thank you for your kind reply Michael, it got me some bit further and I
think I understand a bit more. I could not see any examples of the usage
of the BundleUtilities in CMake, but the example given in the Wiki works
as expected on my machine.
I forgot to add some significant parts of my CMakeLists.txt file. I have
also made some fixes, so the current parts look like this:
...
if (APPLE)
# So that we get the system X11 libraries if they exist:
set(CMAKE_LIBRARY_PATH /usr/lib/ /usr/X11/lib/ ${CMAKE_LIBRARY_PATH})
endif (APPLE)
...
if(APPLE)
SET(MACOSX_BUNDLE_STARTUP_COMMAND madx${BINARY_POSTFIX})
SET(MACOSX_BUNDLE_ICON_FILE
${CMAKE_CURRENT_SOURCE_DIR}/cmakesrc/MadX.icns)
SET(MACOSX_BUNDLE_LONG_VERSION_STRING MadX ${BINARY_POSTFIX} version
${madX_MAJOR_VERSION}.${madX_MINOR_VERSION}.${madX_PATCH_LEVEL})
SET(MACOSX_BUNDLE_BUNDLE_NAME MadX${BINARY_POSTFIX})
SET(MACOSX_BUNDLE_GUI_IDENTIFIER MadX${BINARY_POSTFIX})
# add icns to the .app/Resources with these TWO commands:
SET(srcfiles ${srcfiles} ${CMAKE_CURRENT_SOURCE_DIR}/cmakesrc/MadX.icns)
SET_SOURCE_FILES_PROPERTIES(${CMAKE_CURRENT_SOURCE_DIR}/cmakesrc/MadX.icns
PROPERTIES MACOSX_PACKAGE_LOCATION Resources)
endif(APPLE)
add_executable(madx${BINARY_POSTFIX} MACOSX_BUNDLE ${srcfiles})
SET_TARGET_PROPERTIES(madx${BINARY_POSTFIX} PROPERTIES LINKER_LANGUAGE
Fortran)
...
FIND_PACKAGE(X11)
IF(X11_FOUND)
message(Found X11 libraries)
INCLUDE_DIRECTORIES(${X11_INCLUDE_DIR})
TARGET_LINK_LIBRARIES(madx${BINARY_POSTFIX} ${X11_X11_LIB})
ENDIF(X11_FOUND)
...
target_link_libraries(madx${BINARY_POSTFIX} z)
target_link_libraries(madx${BINARY_POSTFIX} pthread)
target_link_libraries(madx${BINARY_POSTFIX} c)
target_link_libraries(madx${BINARY_POSTFIX} gcc_eh)
...
if(APPLE)
set(APPS \${CMAKE_INSTALL_PREFIX}/madx${BINARY_POSTFIX}.app) #
paths to executables
set(DIRS )
message(aps: ${APPS})
INSTALL(CODE
include(BundleUtilities)
message(\aps: ${APPS}\)
fixup_bundle(\${APPS}\ \\ \${DIRS}\)
COMPONENT Runtime)
INSTALL(TARGETS madx${BINARY_POSTFIX}
BUNDLE DESTINATION . COMPONENT Runtime
RUNTIME DESTINATION bin COMPONENT Runtime
)
else(APPLE)
INSTALL(TARGETS madx${BINARY_POSTFIX}
RUNTIME DESTINATION bin
LIBRARY DESTINATION lib
ARCHIVE DESTINATION lib
)
endif(APPLE)
...
# so that we can build dragndrop on osx (actually needed?):
set(CPACK_BINARY_DRAGNDROP ON)
include (CPack)
...
What I don't understand is why it does not work on my own project. From
what I can see you can actually replace the fixup_bundle() in the
example with simply fixup_bundle(\${APPS}\ \\ \\). This still
gives the following result when I check the binary with otools:
otool -L
_CPack_Packages/Darwin/DragNDrop/QtTest-0.1.1-Darwin/QtTest.app/Contents/MacOS/QtTest
_CPack_Packages/Darwin/DragNDrop/QtTest-0.1.1-Darwin/QtTest.app/Contents/MacOS/QtTest:
@executable_path/../Frameworks/QtGui.framework/Versions/4/QtGui
(compatibility version 4.7.0, current version 4.7.0)
@executable_path/../Frameworks/QtCore.framework/Versions/4/QtCore
(compatibility version 4.7.0, current version 4.7.0)
@executable_path/../MacOS/libstdc++.6.dylib (compatibility version
7.0.0, current version 7.13.0)
@executable_path/../MacOS/libgcc_s.1.dylib (compatibility version
1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 125.2.1)
The original shows:
otool -L QtTest.app/Contents/MacOS/QtTest
QtTest.app/Contents/MacOS/QtTest:
/opt/local/libexec/qt4-mac-devel/lib/QtGui.framework/Versions/4/QtGui
(compatibility version 4.7.0, current version 4.7.0)
/opt/local/libexec/qt4-mac-devel/lib/QtCore.framework/Versions/4/QtCore
(compatibility version 4.7.0, current version 4.7.0)
/opt/local/lib/gcc44/libstdc++.6.dylib (compatibility version
7.0.0, current version 7.13.0)
/opt/local/lib/gcc44/libgcc_s.1.dylib (compatibility version 1.0.0,
current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 125.2.1)
So it seems that it by itself figured out that libraries in /opt/local
should be relinked and added to the bundle, whereas the /usr/lib library
can stay as it is. This is great stuff.
Doing the same with mine it fails with the not a valid bundle error. I
have the following original output from otools:
otool -L madx_dev.app/Contents/MacOS/madx_dev
madx_dev.app/Contents/MacOS/madx_dev:
/usr/X11/lib/libX11.6.dylib (compatibility version 9.0.0, current
version 9.0.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version
1.2.3)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 125.2.1)
/opt/local/lib/gcc44/libstdc++.6.dylib (compatibility version
7.0.0, current version 7.13.0)
/opt/local/lib/gcc44/libgfortran.3.dylib (compatibility version
4.0.0, current version 4.0.0)
/opt/local/lib/gcc44/libgcc_s.1.dylib (compatibility version 1.0.0,
Re: [CMake] How to query compiler definitions?
get_directory_property(info COMPILE_DEFINITIONS) How do you think about an extension for this programming interface? Would you like to support that target parameters like preprocessor symbols are queried from the build environment even if they were not set by the CMake command add_definitions explicitly? Regards, Markus ___ 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] How to assign data from subexpressions of regular expressions to CMake variables?
On 01/20/2011 12:10 PM, SF Markus Elfring wrote:
Thanks for your help to make CMake better,
Is the command variant string(REGEX REPLACE ...) completely documented?
Can multiple variables be specified that will receive the data from the
evaluation of subexpressions in the passed regular expression?
Regards,
Markus
AFAIK no, but you can misuse if(string|varname MATCHES pattern)
for this. It stores the groups in CMAKE_MATCH_n where n is {0..9}.
Match 0 is always the whole match of pattern and match 1 is the
contains the first group.
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
Re: [CMake] How to query compiler definitions?
On 01/20/2011 01:30 PM, SF Markus Elfring wrote: get_directory_property(info COMPILE_DEFINITIONS) How do you think about an extension for this programming interface? Would you like to support that target parameters like preprocessor symbols are queried from the build environment even if they were not set by the CMake command add_definitions explicitly? Regards, Markus Probably that would be pretty difficult to achieve and definitely would break backwards-compatibility beyond resurrection. OTOH, I really think that you're on the wrong track here. You shouldn't check for a preprocessor symbol in CMake. Instead, probably do a find_package(TinyXML) and then depending on the result offer the user an option variable (e.g. ENABLE_DEBUGGING_FUNCTIONS), define a preprocessor symbol HAVE_TINYXML which you then use in your code together with NDEBUG to determine whether to - don't call the debugging functions at all (NDEBUG defined) - either provide dummy/stub debugging functions or #error out (NDEBUG and HAVE_TINYXML not defined) - call the debugging functions (NDEBUG not defined, HAVE_TINYXML defined) This would put the load on the users shoulders, but it should be pretty clear for him what is expected and how to handle things. The INSTALL document can also help there. 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
Re: [CMake] How to assign data from subexpressions of regular expressions to CMake variables?
On Thu, Jan 20, 2011 at 7:39 AM, Michael Wild them...@gmail.com wrote:
On 01/20/2011 12:10 PM, SF Markus Elfring wrote:
Thanks for your help to make CMake better,
Is the command variant string(REGEX REPLACE ...) completely documented?
Can multiple variables be specified that will receive the data from the
evaluation of subexpressions in the passed regular expression?
Regards,
Markus
AFAIK no, but you can misuse if(string|varname MATCHES pattern)
for this. It stores the groups in CMAKE_MATCH_n where n is {0..9}.
Match 0 is always the whole match of pattern and match 1 is the
contains the first group.
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
I think it's the case that the CMAKE_MATCH_* variables are set after *any*
regex matching operation, be it from an if(... MATCHES ...) or a
string(REGEX or string(MATCH command. Let us know if you find that not
to be true.
From the bottom of (
http://cmake.org/cmake/help/cmake-2-8-docs.html#command:string ) :
() Saves a matched subexpression, which can be referenced
in the REGEX REPLACE operation. Additionally it is saved
by all regular expression-related commands, including
e.g. if( MATCHES ), in the variables CMAKE_MATCH_(0..9).
HTH,
David
___
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] How to assign data from subexpressions of regular expressions to CMake variables?
On 01/20/2011 02:01 PM, David Cole wrote:
On Thu, Jan 20, 2011 at 7:39 AM, Michael Wild them...@gmail.com wrote:
On 01/20/2011 12:10 PM, SF Markus Elfring wrote:
Thanks for your help to make CMake better,
Is the command variant string(REGEX REPLACE ...) completely documented?
Can multiple variables be specified that will receive the data from the
evaluation of subexpressions in the passed regular expression?
Regards,
Markus
AFAIK no, but you can misuse if(string|varname MATCHES pattern)
for this. It stores the groups in CMAKE_MATCH_n where n is {0..9}.
Match 0 is always the whole match of pattern and match 1 is the
contains the first group.
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
I think it's the case that the CMAKE_MATCH_* variables are set after *any*
regex matching operation, be it from an if(... MATCHES ...) or a
string(REGEX or string(MATCH command. Let us know if you find that not
to be true.
From the bottom of (
http://cmake.org/cmake/help/cmake-2-8-docs.html#command:string ) :
() Saves a matched subexpression, which can be referenced
in the REGEX REPLACE operation. Additionally it is saved
by all regular expression-related commands, including
e.g. if( MATCHES ), in the variables CMAKE_MATCH_(0..9).
HTH,
David
Ah, yes. I keep forgetting. Might I propose that the documentation about
regular expressions be extracted into its own section and then be
referenced from all commands that have a REGEX mode? Because,
confusingly, the only documentation about regular expression is at the
end of the string(REGEX REPLACE) command, but then uses if(... MATCHES
...) as an example. For the reader of the if( MATCHES ) documentation,
this isn't very discoverable, it doesn't even refer him to the
string(REGEX REPLACE) command.
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
Re: [CMake] How to assign data from subexpressions of regular expressions to CMake variables?
On 01/20/2011 02:14 PM, David Cole wrote:
On Thu, Jan 20, 2011 at 8:06 AM, Michael Wild them...@gmail.com wrote:
On 01/20/2011 02:01 PM, David Cole wrote:
On Thu, Jan 20, 2011 at 7:39 AM, Michael Wild them...@gmail.com wrote:
On 01/20/2011 12:10 PM, SF Markus Elfring wrote:
Thanks for your help to make CMake better,
Is the command variant string(REGEX REPLACE ...) completely
documented?
Can multiple variables be specified that will receive the data from the
evaluation of subexpressions in the passed regular expression?
Regards,
Markus
AFAIK no, but you can misuse if(string|varname MATCHES pattern)
for this. It stores the groups in CMAKE_MATCH_n where n is {0..9}.
Match 0 is always the whole match of pattern and match 1 is the
contains the first group.
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
I think it's the case that the CMAKE_MATCH_* variables are set after
*any*
regex matching operation, be it from an if(... MATCHES ...) or a
string(REGEX or string(MATCH command. Let us know if you find that
not
to be true.
From the bottom of (
http://cmake.org/cmake/help/cmake-2-8-docs.html#command:string ) :
() Saves a matched subexpression, which can be referenced
in the REGEX REPLACE operation. Additionally it is saved
by all regular expression-related commands, including
e.g. if( MATCHES ), in the variables CMAKE_MATCH_(0..9).
HTH,
David
Ah, yes. I keep forgetting. Might I propose that the documentation about
regular expressions be extracted into its own section and then be
referenced from all commands that have a REGEX mode? Because,
confusingly, the only documentation about regular expression is at the
end of the string(REGEX REPLACE) command, but then uses if(... MATCHES
...) as an example. For the reader of the if( MATCHES ) documentation,
this isn't very discoverable, it doesn't even refer him to the
string(REGEX REPLACE) command.
Michael
Me too. I had to go searching for CMAKE_MATCH_ because I knew it was
stated somewhere. Much to my surprise, there was only a single CMAKE_MATCH
on our whole documentation page. It would make sense to document the
variables CMAKE_MATCH_0 and friends explicitly. And cross-referencing left,
right, north and south would also be good.
You can propose all you want. I keep getting distracted by the real bugs
on my plate...
:-)
;-) Right. Anyways, some newbie doing serious RTFM as he should will
stumble across the string(REGEX REPLACE) documentation any ways and
connect the dots :-P
___
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] How to assign data from subexpressions of regular expressions to CMake variables?
On Thu, Jan 20, 2011 at 8:06 AM, Michael Wild them...@gmail.com wrote:
On 01/20/2011 02:01 PM, David Cole wrote:
On Thu, Jan 20, 2011 at 7:39 AM, Michael Wild them...@gmail.com wrote:
On 01/20/2011 12:10 PM, SF Markus Elfring wrote:
Thanks for your help to make CMake better,
Is the command variant string(REGEX REPLACE ...) completely
documented?
Can multiple variables be specified that will receive the data from the
evaluation of subexpressions in the passed regular expression?
Regards,
Markus
AFAIK no, but you can misuse if(string|varname MATCHES pattern)
for this. It stores the groups in CMAKE_MATCH_n where n is {0..9}.
Match 0 is always the whole match of pattern and match 1 is the
contains the first group.
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
I think it's the case that the CMAKE_MATCH_* variables are set after
*any*
regex matching operation, be it from an if(... MATCHES ...) or a
string(REGEX or string(MATCH command. Let us know if you find that
not
to be true.
From the bottom of (
http://cmake.org/cmake/help/cmake-2-8-docs.html#command:string ) :
() Saves a matched subexpression, which can be referenced
in the REGEX REPLACE operation. Additionally it is saved
by all regular expression-related commands, including
e.g. if( MATCHES ), in the variables CMAKE_MATCH_(0..9).
HTH,
David
Ah, yes. I keep forgetting. Might I propose that the documentation about
regular expressions be extracted into its own section and then be
referenced from all commands that have a REGEX mode? Because,
confusingly, the only documentation about regular expression is at the
end of the string(REGEX REPLACE) command, but then uses if(... MATCHES
...) as an example. For the reader of the if( MATCHES ) documentation,
this isn't very discoverable, it doesn't even refer him to the
string(REGEX REPLACE) command.
Michael
Me too. I had to go searching for CMAKE_MATCH_ because I knew it was
stated somewhere. Much to my surprise, there was only a single CMAKE_MATCH
on our whole documentation page. It would make sense to document the
variables CMAKE_MATCH_0 and friends explicitly. And cross-referencing left,
right, north and south would also be good.
You can propose all you want. I keep getting distracted by the real bugs
on my plate...
:-)
___
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 bundle on osx
If you are creating a command line program then the included fixup_bundle will
not work since it looks for a .app folder structure to fix. Instead you
probably want to pass in the path to the executable located in
${CMAKE_INSTALL_PREFIX}/bin/MyExecutable to BundleUtilities.
Any library located in /usr/lib or System/Library/* will NOT be copied into
your bundle/Folder structure as those are considered system libraries and
available on every OS X system.
--
Mike Jackson www.bluequartz.net
On Jan 20, 2011, at 6:15 AM, Yngve Inntjore Levinsen wrote:
Thank you for your kind reply Michael, it got me some bit further and I think
I understand a bit more. I could not see any examples of the usage of the
BundleUtilities in CMake, but the example given in the Wiki works as expected
on my machine.
I forgot to add some significant parts of my CMakeLists.txt file. I have also
made some fixes, so the current parts look like this:
...
if (APPLE)
# So that we get the system X11 libraries if they exist:
set(CMAKE_LIBRARY_PATH /usr/lib/ /usr/X11/lib/ ${CMAKE_LIBRARY_PATH})
endif (APPLE)
...
if(APPLE)
SET(MACOSX_BUNDLE_STARTUP_COMMAND madx${BINARY_POSTFIX})
SET(MACOSX_BUNDLE_ICON_FILE ${CMAKE_CURRENT_SOURCE_DIR}/cmakesrc/MadX.icns)
SET(MACOSX_BUNDLE_LONG_VERSION_STRING MadX ${BINARY_POSTFIX} version
${madX_MAJOR_VERSION}.${madX_MINOR_VERSION}.${madX_PATCH_LEVEL})
SET(MACOSX_BUNDLE_BUNDLE_NAME MadX${BINARY_POSTFIX})
SET(MACOSX_BUNDLE_GUI_IDENTIFIER MadX${BINARY_POSTFIX})
# add icns to the .app/Resources with these TWO commands:
SET(srcfiles ${srcfiles} ${CMAKE_CURRENT_SOURCE_DIR}/cmakesrc/MadX.icns)
SET_SOURCE_FILES_PROPERTIES(${CMAKE_CURRENT_SOURCE_DIR}/cmakesrc/MadX.icns
PROPERTIES MACOSX_PACKAGE_LOCATION Resources)
endif(APPLE)
add_executable(madx${BINARY_POSTFIX} MACOSX_BUNDLE ${srcfiles})
SET_TARGET_PROPERTIES(madx${BINARY_POSTFIX} PROPERTIES LINKER_LANGUAGE
Fortran)
...
FIND_PACKAGE(X11)
IF(X11_FOUND)
message(Found X11 libraries)
INCLUDE_DIRECTORIES(${X11_INCLUDE_DIR})
TARGET_LINK_LIBRARIES(madx${BINARY_POSTFIX} ${X11_X11_LIB})
ENDIF(X11_FOUND)
...
target_link_libraries(madx${BINARY_POSTFIX} z)
target_link_libraries(madx${BINARY_POSTFIX} pthread)
target_link_libraries(madx${BINARY_POSTFIX} c)
target_link_libraries(madx${BINARY_POSTFIX} gcc_eh)
...
if(APPLE)
set(APPS \${CMAKE_INSTALL_PREFIX}/madx${BINARY_POSTFIX}.app) # paths to
executables
set(DIRS )
message(aps: ${APPS})
INSTALL(CODE
include(BundleUtilities)
message(\aps: ${APPS}\)
fixup_bundle(\${APPS}\ \\ \${DIRS}\)
COMPONENT Runtime)
INSTALL(TARGETS madx${BINARY_POSTFIX}
BUNDLE DESTINATION . COMPONENT Runtime
RUNTIME DESTINATION bin COMPONENT Runtime
)
else(APPLE)
INSTALL(TARGETS madx${BINARY_POSTFIX}
RUNTIME DESTINATION bin
LIBRARY DESTINATION lib
ARCHIVE DESTINATION lib
)
endif(APPLE)
...
# so that we can build dragndrop on osx (actually needed?):
set(CPACK_BINARY_DRAGNDROP ON)
include (CPack)
...
What I don't understand is why it does not work on my own project. From what
I can see you can actually replace the fixup_bundle() in the example with
simply fixup_bundle(\${APPS}\ \\ \\). This still gives the following
result when I check the binary with otools:
otool -L
_CPack_Packages/Darwin/DragNDrop/QtTest-0.1.1-Darwin/QtTest.app/Contents/MacOS/QtTest
_CPack_Packages/Darwin/DragNDrop/QtTest-0.1.1-Darwin/QtTest.app/Contents/MacOS/QtTest:
@executable_path/../Frameworks/QtGui.framework/Versions/4/QtGui
(compatibility version 4.7.0, current version 4.7.0)
@executable_path/../Frameworks/QtCore.framework/Versions/4/QtCore
(compatibility version 4.7.0, current version 4.7.0)
@executable_path/../MacOS/libstdc++.6.dylib (compatibility version 7.0.0,
current version 7.13.0)
@executable_path/../MacOS/libgcc_s.1.dylib (compatibility version 1.0.0,
current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
125.2.1)
The original shows:
otool -L QtTest.app/Contents/MacOS/QtTest
QtTest.app/Contents/MacOS/QtTest:
/opt/local/libexec/qt4-mac-devel/lib/QtGui.framework/Versions/4/QtGui
(compatibility version 4.7.0, current version 4.7.0)
/opt/local/libexec/qt4-mac-devel/lib/QtCore.framework/Versions/4/QtCore
(compatibility version 4.7.0, current version 4.7.0)
/opt/local/lib/gcc44/libstdc++.6.dylib (compatibility version 7.0.0,
current version 7.13.0)
/opt/local/lib/gcc44/libgcc_s.1.dylib (compatibility version 1.0.0,
current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
125.2.1)
So it seems that it by itself figured out that libraries in /opt/local should
be relinked and added to the bundle, whereas the /usr/lib library can stay as
it is. This is great stuff.
Doing the same with mine it fails with the not a valid bundle error. I have
the following original output from otools:
Re: [CMake] How to query compiler definitions?
Probably that would be pretty difficult to achieve and definitely would break backwards-compatibility beyond resurrection. I have got a different opinion. I imagine that a property with a new name can provide the desired service to retrieve target parameters in a portable way from the build environment. Otherwise: Would the addition of a CMake command make more sense for this purpose? You shouldn't check for a preprocessor symbol in CMake. It's just the way I would prefer to adapt the build process to the requirements of the source files at the moment. It seems that the evaluation of compilation parameters (variable CMAKE_CXX_FLAGS...) with regular expressions is an approach that will currently work to some degree. The used pattern determines how many compilers will be supported. Instead, probably do a find_package(TinyXML) I would appreciate if a corresponding module (search script) will become generally available for CMake. and then depending on the result offer the user an option variable I guess that the term user needs to be distinguished for its various meanings. There are some switches involved that might only interest a subset of them. - software developers - system integrators - tool users Regards, Markus ___ 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] How to make a ProjectConfig.cmake
On 01/19/2011 07:24 PM, Alexander Neundorf wrote:
On Thursday 30 December 2010, Michael Wild wrote:
On 12/30/2010 11:33 AM, Ian Monroe wrote:
To create my QyotoConfig.cmake I need to know the full path of a
library so that I can set a variable like QYOTO_LIBRARY.
This is pretty standard requirement right? Its what we're supposed to
do in *Config.cmake's?
So anyways, how do I that? The only target property that hasn't
returned NOTFOUND is LOCATION, which unhelpfully returns the location
of the library in the build directory. I could parse this to get the
file name, and then append it to the library install location... but
that seems like such a hack. Feels like I'm doing something wrong if I
need to use a hack to do something standard.
I looked at install(EXPORT which could work, but it seems to include a
lot more information then is needed. I just want to set a variable
with the full path to a library.
Ian
That's not how *Config.cmake modules work. They're NOT Find*.cmake
modules. You should:
- add the targets to an export-set for usage from the build tree:
export(TARGETS ...
FILE ${CMAKE_BINARY_DIR}/${PROJECT_NAME}LibraryDepends.cmake)
- add the targets to an export-set for installation:
install(TARGETS ... EXPORT ${CMAKE_PROJECT_NAME}LibraryDepends ...)
- export the package for usage from the build tree (enter into some
global registry):
export(PACKAGE ${PROJECT_NAME})
- create a *Config.cmake file for the use from the build tree:
set(QYOTO_INCLUDE_DIR ${CMAKE_SOURCE_DIR})
set(QYOTO_LIB_DIR ${CMAKE_BINARY_DIR}/lib)
set(QYOTO_CMAKE_DIR ${CMAKE_BINARY_DIR})
configure_file(${CMAKE_PROJECT_NAME}Config.cmake.in
${CMAKE_BINARY_DIR}/${CMAKE_PROJECT_NAME}Config.cmake @ONLY)
- install the export set:
install(EXPORT ${CMAKE_PROJECT_NAME}LibraryDepends DESTINATION
share/${CMAKE_PROJECT_NAME}/CMake)
- create a *Config.cmake file for the use from the install tree and
install it:
set(QYOTO_INCLUDE_DIR ${CMAKE_INSTALL_PREFIX}/include)
set(QYOTO_LIB_DIR ${CMAKE_INSTALL_PREFIX}/lib)
set(QYOTO_CMAKE_DIR
${CMAKE_INSTALL_PREFIX}/share/${CMAKE_PROJECT_NAME}/CMake)
configure_file(${CMAKE_PROJECT_NAME}Config.cmake.in
${CMAKE_BINARY_DIR}/InstallFiles/${CMAKE_PROJECT_NAME}Config.cmake
@ONLY)
install(FILES
${CMAKE_BINARY_DIR}/InstallFiles/${CMAKE_PROJECT_NAME}Config.cmake
DESTINATION share/${CMAKE_PROJECT_NAME}/CMake)
- The *Config.cmake.in could look like this:
###
# Tell the user project where to find our headers and libraries
set(QYOTO_INCLUDE_DIR @QYOTO_INCLUDE_DIR@)
set(QYOTO_INCLUDE_DIRS ${QYOTO_INCLUDE_DIR})
set(QYOTO_LIBRARY_DIRS @QYOTO_LIB_DIR@)
# Our library dependencies (contains definitions for IMPORTED targets)
include(@QYOTO_CMAKE_DIR@/@PROJECT_NAME@LibraryDepends.cmake)
# Defines (if required)
set(QYOTO_DEFINITIONS @QYOTO_COMPILE_DEFINITIONS@)
# USE file (if you have one)
set(QYOTO_USE_FILE
@QYOTO_CMAKE_DIR@/@PROJECT_NAME@Use.cmake
)
###
As you can see, the QYOTO_INCLUDE_DIR, QYOTO_LIB_DIR and QYOTO_CMAKE_DIR
values will differ between build and install tree, which is why you
should configure it twice, once for installation and once for the use
from the build tree.
- If you want to get fancy, you can also provide a *ConfigVersion.cmake
file. This file should set the following variables, depending on the
variables PACKAGE_FIND_NAME, PACKAGE_FIND_VERSION,
PACKAGE_FIND_VERSION_{MAJOR,MINOR,PATCH,TWEAK,COUNT}:
- PACKAGE_VERSION (version string)
- PACKAGE_VERSION_EXACT (TRUE or FALSE)
- PACKAGE_VERSION_COMPATIBLE (TRUE or FALSE)
- PACKAGE_VERSION_UNSUITABLE (TRUE or FALSE)
Wow, good summary.
Can you please put that in a wiki page on http://www.cmake.org/Wiki/CMake ?
Thanks :-)
Alex
http://www.cmake.org/Wiki/CMake:How_to_create_a_ProjectConfig.cmake_file
What do you think? Text is pretty terse, but the code should cover it...
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
Re: [CMake] How to query compiler definitions?
On 01/20/2011 04:30 PM, SF Markus Elfring wrote: Probably that would be pretty difficult to achieve and definitely would break backwards-compatibility beyond resurrection. I have got a different opinion. I imagine that a property with a new name can provide the desired service to retrieve target parameters in a portable way from the build environment. Otherwise: Would the addition of a CMake command make more sense for this purpose? A single property wouldn't do, you would need one for every configuration and the general configuration, e.g. - ALL_COMPILE_DEFINITIONS - ALL_COMPILE_DEFINITIONS_DEBUG - ALL_COMPILE_DEFINITIONS_RELEASE - ALL_COMPILE_DEFINITIONS_MINSIZEREL - ALL_COMPILE_DEFINITIONS_RELWITHDEBUGINFO - plus other, user-defined configurations These properties would need to read-only and available for directories, source files and targets. That's a lot of work, but if it scratches your itch, go ahead, get hackin' ;-) You shouldn't check for a preprocessor symbol in CMake. It's just the way I would prefer to adapt the build process to the requirements of the source files at the moment. It seems that the evaluation of compilation parameters (variable CMAKE_CXX_FLAGS...) with regular expressions is an approach that will currently work to some degree. The used pattern determines how many compilers will be supported. I don't think that the string NDEBUG is so common, so you could just check for that and don't worry about the specific compiler flag. Instead, probably do a find_package(TinyXML) I would appreciate if a corresponding module (search script) will become generally available for CMake. You could write one ;-) You could also include a private version of that script in your project and then append its location to the CMAKE_MODULE_PATH variable. and then depending on the result offer the user an option variable I guess that the term user needs to be distinguished for its various meanings. There are some switches involved that might only interest a subset of them. - software developers - system integrators - tool users User here means the dude who downloaded your package from SF and tries to build it on his machine. :-) To hide uninteresting switches, you can use the mark_as_advanced() command. 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
Re: [CMake] How to query compiler definitions?
2011/1/20 SF Markus Elfring elfr...@users.sourceforge.net: Probably that would be pretty difficult to achieve and definitely would break backwards-compatibility beyond resurrection. I have got a different opinion. I imagine that a property with a new name can provide the desired service to retrieve target parameters in a portable way from the build environment. Otherwise: Would the addition of a CMake command make more sense for this purpose? You shouldn't check for a preprocessor symbol in CMake. It's just the way I would prefer to adapt the build process to the requirements of the source files at the moment. It seems that the evaluation of compilation parameters (variable CMAKE_CXX_FLAGS...) with regular expressions is an approach that will currently work to some degree. The used pattern determines how many compilers will be supported. Instead, probably do a find_package(TinyXML) I would appreciate if a corresponding module (search script) will become generally available for CMake. and then depending on the result offer the user an option variable I guess that the term user needs to be distinguished for its various meanings. There are some switches involved that might only interest a subset of them. When you have such different levels of option you may do something like: OPTION(DEVELOPER_OPT_ENABLE Enable developer options OFF) OPTION(SYSTEM_INTEGRATOR_OPT_ENABLE Enable system integrator specific options OFF) OPTION(TOOL_USERS_OPT_ENABLE Enable tool users options ON) - software developers - system integrators - tool users then you do IF (DEVELOPER_OPT_ENABLE) OPTION(DEV_OPT1 blah blah ON) OPTION(DEV_OPT2 blah blah OFF) ENDIF(DEVELOPER_OPT_ENABLE) IF (TOOL_USERS_OPT_ENABLE) OPTION(USR_OPT1 blah blah ON) OPTION(USR_OPT2 blah blah OFF) OPTION(USR_OPT3 blah blah ON) ENDIF(TOOL_USERS_OPT_ENABLE) so an option may perfectly depend on another option, such kind of config may need several configure steps but its works well (at least for me). With sensible default option value average user will get its appropriate option in CMake GUI whereas developers knows how to get more. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.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] How to make a ProjectConfig.cmake
On Thursday 20 January 2011, Michael Wild wrote:
On 01/19/2011 07:24 PM, Alexander Neundorf wrote:
On Thursday 30 December 2010, Michael Wild wrote:
On 12/30/2010 11:33 AM, Ian Monroe wrote:
To create my QyotoConfig.cmake I need to know the full path of a
library so that I can set a variable like QYOTO_LIBRARY.
This is pretty standard requirement right? Its what we're supposed to
do in *Config.cmake's?
So anyways, how do I that? The only target property that hasn't
returned NOTFOUND is LOCATION, which unhelpfully returns the location
of the library in the build directory. I could parse this to get the
file name, and then append it to the library install location... but
that seems like such a hack. Feels like I'm doing something wrong if I
need to use a hack to do something standard.
I looked at install(EXPORT which could work, but it seems to include a
lot more information then is needed. I just want to set a variable
with the full path to a library.
Ian
That's not how *Config.cmake modules work. They're NOT Find*.cmake
modules. You should:
- add the targets to an export-set for usage from the build tree:
export(TARGETS ...
FILE ${CMAKE_BINARY_DIR}/${PROJECT_NAME}LibraryDepends.cmake)
- add the targets to an export-set for installation:
install(TARGETS ... EXPORT ${CMAKE_PROJECT_NAME}LibraryDepends ...)
- export the package for usage from the build tree (enter into some
global registry):
export(PACKAGE ${PROJECT_NAME})
- create a *Config.cmake file for the use from the build tree:
set(QYOTO_INCLUDE_DIR ${CMAKE_SOURCE_DIR})
set(QYOTO_LIB_DIR ${CMAKE_BINARY_DIR}/lib)
set(QYOTO_CMAKE_DIR ${CMAKE_BINARY_DIR})
configure_file(${CMAKE_PROJECT_NAME}Config.cmake.in
${CMAKE_BINARY_DIR}/${CMAKE_PROJECT_NAME}Config.cmake @ONLY)
- install the export set:
install(EXPORT ${CMAKE_PROJECT_NAME}LibraryDepends DESTINATION
share/${CMAKE_PROJECT_NAME}/CMake)
- create a *Config.cmake file for the use from the install tree and
install it:
set(QYOTO_INCLUDE_DIR ${CMAKE_INSTALL_PREFIX}/include)
set(QYOTO_LIB_DIR ${CMAKE_INSTALL_PREFIX}/lib)
set(QYOTO_CMAKE_DIR
${CMAKE_INSTALL_PREFIX}/share/${CMAKE_PROJECT_NAME}/CMake)
configure_file(${CMAKE_PROJECT_NAME}Config.cmake.in
${CMAKE_BINARY_DIR}/InstallFiles/${CMAKE_PROJECT_NAME}Config.cmake
@ONLY)
install(FILES
${CMAKE_BINARY_DIR}/InstallFiles/${CMAKE_PROJECT_NAME}Config.cmake
DESTINATION share/${CMAKE_PROJECT_NAME}/CMake)
- The *Config.cmake.in could look like this:
###
# Tell the user project where to find our headers and libraries
set(QYOTO_INCLUDE_DIR @QYOTO_INCLUDE_DIR@)
set(QYOTO_INCLUDE_DIRS ${QYOTO_INCLUDE_DIR})
set(QYOTO_LIBRARY_DIRS @QYOTO_LIB_DIR@)
# Our library dependencies (contains definitions for IMPORTED targets)
include(@QYOTO_CMAKE_DIR@/@PROJECT_NAME@LibraryDepends.cmake)
# Defines (if required)
set(QYOTO_DEFINITIONS @QYOTO_COMPILE_DEFINITIONS@)
# USE file (if you have one)
set(QYOTO_USE_FILE
@QYOTO_CMAKE_DIR@/@PROJECT_NAME@Use.cmake
)
###
As you can see, the QYOTO_INCLUDE_DIR, QYOTO_LIB_DIR and QYOTO_CMAKE_DIR
values will differ between build and install tree, which is why you
should configure it twice, once for installation and once for the use
from the build tree.
- If you want to get fancy, you can also provide a *ConfigVersion.cmake
file. This file should set the following variables, depending on the
variables PACKAGE_FIND_NAME, PACKAGE_FIND_VERSION,
PACKAGE_FIND_VERSION_{MAJOR,MINOR,PATCH,TWEAK,COUNT}:
- PACKAGE_VERSION (version string)
- PACKAGE_VERSION_EXACT (TRUE or FALSE)
- PACKAGE_VERSION_COMPATIBLE (TRUE or FALSE)
- PACKAGE_VERSION_UNSUITABLE (TRUE or FALSE)
Wow, good summary.
Can you please put that in a wiki page on http://www.cmake.org/Wiki/CMake
?
Thanks :-)
Alex
http://www.cmake.org/Wiki/CMake:How_to_create_a_ProjectConfig.cmake_file
What do you think? Text is pretty terse, but the code should cover it...
Great :-)
I would move the link to the page to a a bit up on the main page, so it's
easier to find.
Maybe that overview page needs some shuffling around again.
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] Should CMake use /etc/ld.so.conf.d for find_library's CMAKE_SYSTEM_LIBRARY_PATH?
On Thursday 20 January 2011, James Bigler wrote: I'm noticing that on some systems they package the NVIDIA driver into different directories than the driver is typically installed. In order to make stuff link properly at run time these non-standard locations are added to /etc/ld.so.conf.d. I'm wondering if there is a reason not to use this information to add paths to CMAKE_SYSTEM_LIBRARY_PATH? It would certainly help in finding libraries that are installed in diverse places. Sounds like a useful idea IMO. It could be done in UnixPaths.cmake, if /etc/ld.so.conf exists, parse it, get the directories from it, check for duplicates, and add them to the search paths. Do you think it should be only added to the library search path or should the /lib at the end of each directory be removed and the remainder be added to the general search prefixes ? Otherwise it might now find the libs, but maybe not the corresponding headers. 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] add_custom_target and Code Blocks generator
On Thursday 20 January 2011, Dimitri Kaparis wrote: Greetings, the Code Blocks generator is not adding to the project the sources, specified in the command. In order to add a group of header files to my project tree, I'm trying to implement the solution posted here: http://www.cmake.org/pipermail/cmake/2010-November/040537.html The target itself is added to the Code Blocks project, however the source files are not. Should I file a bug report? Are there any other workarounds for that use case, besides adding the headers to some other existing executable or library target? This is under linux, with CMake release 2.8.3. add_custom_target() does not have a list of source files. Which behaviour do you expect ? Can you post a small example CMakeLists.txt and explain what you would expect ? Thanks 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] How to assign data from subexpressions of regular expressions to CMake variables?
On Thursday 20 January 2011, Michael Wild wrote: On 01/20/2011 02:14 PM, David Cole wrote: ... Me too. I had to go searching for CMAKE_MATCH_ because I knew it was stated somewhere. Much to my surprise, there was only a single CMAKE_MATCH on our whole documentation page. It would make sense to document the variables CMAKE_MATCH_0 and friends explicitly. And cross-referencing left, right, north and south would also be good. You can propose all you want. I keep getting distracted by the real bugs on my plate... :-) ;-) Right. Anyways, some newbie doing serious RTFM as he should will stumble across the string(REGEX REPLACE) documentation any ways and connect the dots :-P I think Dave meant Please write a patch which adds the documentation and put this in the bugtracker :-) Alexy ___ 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] Should CMake use /etc/ld.so.conf.d for find_library's CMAKE_SYSTEM_LIBRARY_PATH?
On Thursday 20 January 2011, James Bigler wrote: I'm noticing that on some systems they package the NVIDIA driver into different directories than the driver is typically installed. In order to make stuff link properly at run time these non-standard locations are added to /etc/ld.so.conf.d. I'm wondering if there is a reason not to use this information to add paths to CMAKE_SYSTEM_LIBRARY_PATH? It would certainly help in finding libraries that are installed in diverse places. Sounds like a useful idea IMO. It could be done in UnixPaths.cmake, if /etc/ld.so.conf exists, parse it, get the directories from it, check for duplicates, and add them to the search paths. Sounds indeed sane. But be aware that this file may contain include directives with glob expressions, usually something like /etc/ld.so.conf.d/*.conf. If you don't follow them you will hardly find anything on modern distros. Eike ___ 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] Restrictions on where a binary can be put?
On Sunday 09 January 2011, Michael Hertling wrote:
On 01/09/2011 09:47 PM, Nizar Khalifa Sallem wrote:
At Sun, 09 Jan 2011 21:42:49 +0100,
Michael Hertling wrote:
On 01/09/2011 09:09 PM, Andreas Pakulat wrote:
On 09.01.11 21:05:21, Andreas Pakulat wrote:
On 09.01.11 14:24:16, Michael Hertling wrote:
On 01/09/2011 12:58 PM, Andreas Pakulat wrote:
Hi,
I'm having a bit of a problem here changing the runtime output
directory for a binary. Its an executable target named 'setup' and
I'd like to put it into the top-level directory. Unfortunately it
always ends up in the bin/ directory, which is what
CMAKE_RUNTIME_OUTPUT_DIRECTORY is being set to.
I'm using
set_target_properties( setup PROPERTIES RUNTIME_OUTPUT_DIRECTORY
${CMAKE_BINARY_DIR} ) after creating the target currently, which
should work as far as I can see from the documentation. Are there
maybe any restrictions on what the directory may be or what targets
can be put there?
If not, any suggestions how to debug this? I can see that the
build.make does already have the rule setup for putting the binary
into bin/, so it must be going wrong somewhere in the generation
stage, but a simple cmake --trace doesn't show up anything
suspicious. Is there a switch to follow the steps that cmake does
during makefile-generation?
Could you provide a minimal but complete example?
Ok, attached case produces the error. Apparently the problem is
fetching the LOCATION property from the target and setting the
RUNTIME_OUTPUT_DIRECTORY afterwards. Looks like a cmake bug to me, so
I'll file a report.
Ooops, forgot the attachment :)
Now, I can confirm the issue; indeed, the GET_TARGET_PROPERTY() on the
LOCATION apparently renders the following SET_TARGET_PROPERTY() on the
RUNTIME_OUTPUT_DIRECTORY ineffective. As I cannot see any reason for
this, I'd agree that it should be considered as a bug. Besides, my
example was pointless: A simple clash of an executable main with
a subdirectory of the same name in CMAKE_BINARY_DIR, sorry. :/
Regards,
Michael
I don't really understand why you want to get the LOCATION from your
target, anyway, the get_target_property works fine if you use
set_target_properties before it. [...]
...but SET_TARGET_PROPERTIES() doesn't work fine if it's used after
GET_TARGET_PROPERTY(), even if both operate on different properties.
Well, they are not completely different.
If I remember correctly, the LOCATION property is calculcated when you query
it. I think it changes some internal variables. Apparently to a state where
setting the target property afterwards doesn't have the desired effect
anymore :-/
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] CHECK_INCLUDE_FILES ignores CMAKE_FIND_ROOT_PATH, but should it?
On Monday 10 January 2011, Bjørn Forsman wrote:
Hi all,
I just found out that CHECK_INCLUDE_FILES ignores CMAKE_FIND_ROOT_PATH. The
documentation for CHECK_INCLUDE_FILES says:
...
The following variables may be set before calling this macro to
modify the way the check is run:
CMAKE_REQUIRED_FLAGS = string of compile command line flags
CMAKE_REQUIRED_DEFINITIONS = list of macros to define (-DFOO=bar)
CMAKE_REQUIRED_INCLUDES = list of include directories
So it seems intentional. But wouldn't it make sense to let
CHECK_INCLUDE_FILES look in CMAKE_FIND_ROOT_PATH? Or maybe more precise,
give the compiler include flags for
CMAKE_FIND_ROOT_PATH/{include/,usr/include}? It just seems wrong to me that
include files in CMAKE_FIND_ROOT_PATH can be ignored like that and it
destroys the meaning of CMAKE_FIND_ROOT_PATH. Comments?
Is maybe CHECK_INCLUDE_FILES deprecated and FIND_PATH/FIND_FILE is the way
to go?
check_include_files() is there to check whether header files in the compilers
system include path exist, i.e. which are found without any -I switches.
So, from that POV, the behaviour is ok.
Can I actually tell the compiler/gcc to ignore its standard include dirs ?
What header files are you testing ?
From libc or from some other library ?
I'm using CMake 2.8.2.
That behaviour didn't change recently.
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] How to assign data from subexpressions of regular expressions to CMake variables?
On Thu, Jan 20, 2011 at 12:37 PM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: On Thursday 20 January 2011, Michael Wild wrote: On 01/20/2011 02:14 PM, David Cole wrote: ... Me too. I had to go searching for CMAKE_MATCH_ because I knew it was stated somewhere. Much to my surprise, there was only a single CMAKE_MATCH on our whole documentation page. It would make sense to document the variables CMAKE_MATCH_0 and friends explicitly. And cross-referencing left, right, north and south would also be good. You can propose all you want. I keep getting distracted by the real bugs on my plate... :-) ;-) Right. Anyways, some newbie doing serious RTFM as he should will stumble across the string(REGEX REPLACE) documentation any ways and connect the dots :-P I think Dave meant Please write a patch which adds the documentation and put this in the bugtracker :-) Alexy Actually, I don't mean to be flippant. Hopefully nobody read my earlier emails that way. But I am serious. There are bigger fish to fry this week... And in lieu of *perfect* documentation, I am (and others are) perfectly willing to point to the hard to find nuggets of documentation when a direct question about something is asked. David ___ 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] Should CMake use /etc/ld.so.conf.d for find_library's CMAKE_SYSTEM_LIBRARY_PATH?
On Thu, Jan 20, 2011 at 10:47 AM, Rolf Eike Beer e...@sf-mail.de wrote:
On Thursday 20 January 2011, James Bigler wrote:
I'm noticing that on some systems they package the NVIDIA driver into
different directories than the driver is typically installed. In
order to make stuff link properly at run time these non-standard
locations are added to /etc/ld.so.conf.d. I'm wondering if there is a
reason not to use this information to add paths to
CMAKE_SYSTEM_LIBRARY_PATH? It would certainly help in finding
libraries that are installed in diverse places.
Sounds like a useful idea IMO.
It could be done in UnixPaths.cmake, if /etc/ld.so.conf exists, parse
it, get the directories from it, check for duplicates, and add them to
the search paths.
Sounds indeed sane. But be aware that this file may contain include
directives with glob expressions, usually something like
/etc/ld.so.conf.d/*.conf. If you don't follow them you will hardly find
anything on modern distros.
Eike
Yeah, the one I'm looking at looks like this:
$ cat ld.so.conf
include /etc/ld.so.conf.d/*.conf
/usr/local/lib
$ for T in ld.so.conf.d/*;do echo $T; cat $T;done
ld.so.conf.d/R-i386.conf
/usr/lib/R/lib
ld.so.conf.d/atlas-i386.conf
/usr/lib/atlas
ld.so.conf.d/cuda-%{arch}.conf
/usr/lib/cuda
ld.so.conf.d/kernel-2.6.35.10-69.fc14.i686.PAE.conf
# Placeholder file, no vDSO hwcap entries used in this kernel.
ld.so.conf.d/kernel-2.6.35.10-72.fc14.i686.PAE.conf
# Placeholder file, no vDSO hwcap entries used in this kernel.
ld.so.conf.d/kernel-2.6.35.10-74.fc14.i686.PAE.conf
# Placeholder file, no vDSO hwcap entries used in this kernel.
ld.so.conf.d/mysql-i386.conf
/usr/lib/mysql
ld.so.conf.d/nvidia-lib.conf
/usr/lib/nvidia
ld.so.conf.d/octave-i386.conf
/usr/lib/octave-3.3.54
ld.so.conf.d/qt-i386.conf
/usr/lib/qt-3.3/lib
ld.so.conf.d/tix-i386.conf
/usr/lib/tcl8.5
ld.so.conf.d/wine-32.conf
/usr/lib/wine/
ld.so.conf.d/xulrunner-32.conf
/usr/lib/xulrunner-1.9.2
ld.so.conf.d/xulrunner2-32.conf
/usr/lib/xulrunner-2
___
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] Cross-compiling a static library (CMake 2.8.3)
On Monday 10 January 2011, Emmanuel Blot wrote: INCLUDE (CMakeForceCompiler) CMAKE_FORCE_C_COMPILER (arm-eabi-gcc-4.5.2 GNU 4) I haven't used that one before. FWIW: I found why I use CMAKE_FORCE_C_COMPILER rather than the simpler CMAKE_C_COMPILER command: I build projects for eCos from outside the eCos tree directory, and CMake has some trouble finding the eCos header files when simply using CMAKE_C_COMPILER. It complains about CMAKE_FIND_ROOT_PATH which is nevertheless defined as expected. You should not need to use CMAKE_FORCE_C_COMPILER() for eCos. Can you please post some more details on your setup ? Where is the eCos tree with libtarget.a etc. ? How does your toolchain file look like ? How do you call cmake ? Do the instructions from that wiki page http://cmake.org/Wiki/CmakeEcos work for you if you use the described setup ? Do they only fail if you use a different setup ? 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] Cross-compiling, CMAKE_C_FLAGS, and configure-time compiler tests
Hi Justin,
On Tuesday 14 December 2010, Justin Holewinski wrote:
On Tue, Dec 14, 2010 at 4:45 AM, Johan Björk p...@spotify.com wrote:
Hi Justin,
I'm very unsure if this is the correct solution, but it worked for me. I
haven't been able to find any good documentation stating how the
CMakeCache interacts with other parts of CMake.
My assumption is that since CMAKE_C{XX}_FLAGS is supposed to allow the
user to set optional compilation flags, it prefers the value in the cache
versus the one from the toolchain file.
From one of my toolchain files, reproduce as necessary for CMAKE_C_FLAGS:
SET(CMAKE_CXX_FLAGS ${CMAKE_C_FLAGS} -fno-rtti CACHE STRING FORCE)
I'll have to give that a try. For now, I'm getting around the problem by
setting the flags within the parent CMakeLists.txt script after loading the
toolchain file.
I'm really not sure what the best practice is for this situation. The
compiler will work and can be tested without the -arch flags, but the
flags are necessary to build for the *right* architecture. Most
cross-compilers will only produce binaries for the target system, so the
point is moot. The iOS compilers, however, will generate code for Intel
and ARM so I'm not sure if testing the i386 back-end when I'm targeting ARM
is the right way or not.
please put your problem in the cmake bug tracker
http://public.kitware.com/Bug/ and assign it to me.
Thanks
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] How to make a ProjectConfig.cmake
On 01/20/2011 12:22 PM, Alexander Neundorf wrote: On Thursday 20 January 2011, Michael Wild wrote: On 01/19/2011 07:24 PM, Alexander Neundorf wrote: Wow, good summary. Can you please put that in a wiki page on http://www.cmake.org/Wiki/CMake? http://www.cmake.org/Wiki/CMake:How_to_create_a_ProjectConfig.cmake_file What do you think? Text is pretty terse, but the code should cover it... Great :-) I would move the link to the page to a a bit up on the main page, so it's easier to find. Maybe that overview page needs some shuffling around again. This all has been documented on the Wiki for years: http://www.cmake.org/Wiki/CMake_2.6_Notes It is more of a tutorial/reference format than an example/template though. -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://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] Specify as in the toolchain
On Friday 03 December 2010, Andrea Galeazzi wrote:
Il 03/12/2010 13.15, Michael Wild ha scritto:
On 12/03/2010 01:06 PM, Andrea Galeazzi wrote:
How can I specify the as command like I do for gcc or g++ compiler in
a toolchain?
SET(CMAKE_C_COMPILER C:/Programmi/development/GCCARM/bin/gcc.exe)
*NEVER* set the compiler like this AFTER you executed the PROJECT or
ENABLE_LANGUAGE commands. This will cause all kinds of failures. In
fact, consider these variables to be read-only. Usually which compiler
to use is either determined by the user running CMake or by CMake itself
if the user didn't specify anything.
If you must override the compiler (really, you shouldn't), have a look
at the CMakeForceCompiler module.
The assembler is in the CMAKE_ASM${DIALECT}_COMPILER variable, but
again, consider this to be read-only. Read
http://www.cmake.org/Wiki/CMake/Assembler for more information.
Michael
__ Informazioni da ESET NOD32 Antivirus, versione del database
delle firme digitali 5670 (20101203) __
Il messaggio è stato controllato da ESET NOD32 Antivirus.
www.nod32.it
Probably my problem is simpler; that's my toolchain file for cross compile:
INCLUDE (CMakeForceCompiler)
CMAKE_FORCE_C_COMPILER (gcc.exe GNU)
CMAKE_FORCE_CXX_COMPILER (gcc.exe GNU)
Is this really necessary ?
Can't you link a basic main.c without any special flags ?
This should be the only case where the force() macros should be used.
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] How to make a ProjectConfig.cmake
On Thursday 20 January 2011, Brad King wrote: On 01/20/2011 12:22 PM, Alexander Neundorf wrote: On Thursday 20 January 2011, Michael Wild wrote: On 01/19/2011 07:24 PM, Alexander Neundorf wrote: Wow, good summary. Can you please put that in a wiki page on http://www.cmake.org/Wiki/CMake? http://www.cmake.org/Wiki/CMake:How_to_create_a_ProjectConfig.cmake_file What do you think? Text is pretty terse, but the code should cover it... Great :-) I would move the link to the page to a a bit up on the main page, so it's easier to find. Maybe that overview page needs some shuffling around again. This all has been documented on the Wiki for years: http://www.cmake.org/Wiki/CMake_2.6_Notes It is more of a tutorial/reference format than an example/template though. Yes, it's just hard to find under the link CMake 2.6 Notes when looking for information on how to create a Config-file. 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] add_custom_target and Code Blocks generator
On Thu, Jan 20, 2011 at 7:27 PM, Alexander Neundorf
a.neundorf-w...@gmx.net wrote:
On Thursday 20 January 2011, Dimitri Kaparis wrote:
Greetings,
the Code Blocks generator is not adding to the project the sources,
specified in the command.
In order to add a group of header files to my project tree, I'm trying
to implement the solution posted here:
http://www.cmake.org/pipermail/cmake/2010-November/040537.html
The target itself is added to the Code Blocks project, however the
source files are not.
Should I file a bug report? Are there any other workarounds for that
use case, besides adding the headers to some other existing executable
or library target?
This is under linux, with CMake release 2.8.3.
add_custom_target() does not have a list of source files. Which behaviour do
you expect ?
Can you post a small example CMakeLists.txt and explain what you would
expect ?
From the documentation at
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:add_custom_target
:
The SOURCES option specifies additional source files to be included
in the custom target. Specified source files will be added to IDE
project files for convenience in editing even if they have not build
rules.
What I'm trying to do is explained in the thread I linked to above. I
have a directory with some utility header files used by several
targets in my project. I want these headers to appear in the list of
sources in Code Block's generated project. So I add a custom target,
listing them as sources:
set(SRCS point.hpp
box.hpp)
add_custom_target(GeometryHeaders SOURCES ${SRCS})
In Code Blocks, however, the header files do not appear in the project
source tree.
I just tried with the MSVC10 generator, and there this adds a project
with the sources listed.
Thanks,
Dimitri
___
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 bundle on osx
Well I do have a folder structure, which looks like this:
$ ls -R madx_dev.app/
Contents
madx_dev.app//Contents:
Info.plist MacOS Resources
madx_dev.app//Contents/MacOS:
madx_dev
madx_dev.app//Contents/Resources:
MadX.icns
But it does not seem that the fixup-command does anything for me with
the current configuration. Don't get why.
On 20 January 2011 15:40, Michael Jackson mike.jack...@bluequartz.net wrote:
If you are creating a command line program then the included fixup_bundle
will not work since it looks for a .app folder structure to fix. Instead
you probably want to pass in the path to the executable located in
${CMAKE_INSTALL_PREFIX}/bin/MyExecutable to BundleUtilities.
Any library located in /usr/lib or System/Library/* will NOT be copied into
your bundle/Folder structure as those are considered system libraries and
available on every OS X system.
--
Mike Jackson www.bluequartz.net
On Jan 20, 2011, at 6:15 AM, Yngve Inntjore Levinsen wrote:
Thank you for your kind reply Michael, it got me some bit further and I
think I understand a bit more. I could not see any examples of the usage of
the BundleUtilities in CMake, but the example given in the Wiki works as
expected on my machine.
I forgot to add some significant parts of my CMakeLists.txt file. I have
also made some fixes, so the current parts look like this:
...
if (APPLE)
# So that we get the system X11 libraries if they exist:
set(CMAKE_LIBRARY_PATH /usr/lib/ /usr/X11/lib/ ${CMAKE_LIBRARY_PATH})
endif (APPLE)
...
if(APPLE)
SET(MACOSX_BUNDLE_STARTUP_COMMAND madx${BINARY_POSTFIX})
SET(MACOSX_BUNDLE_ICON_FILE
${CMAKE_CURRENT_SOURCE_DIR}/cmakesrc/MadX.icns)
SET(MACOSX_BUNDLE_LONG_VERSION_STRING MadX ${BINARY_POSTFIX} version
${madX_MAJOR_VERSION}.${madX_MINOR_VERSION}.${madX_PATCH_LEVEL})
SET(MACOSX_BUNDLE_BUNDLE_NAME MadX${BINARY_POSTFIX})
SET(MACOSX_BUNDLE_GUI_IDENTIFIER MadX${BINARY_POSTFIX})
# add icns to the .app/Resources with these TWO commands:
SET(srcfiles ${srcfiles} ${CMAKE_CURRENT_SOURCE_DIR}/cmakesrc/MadX.icns)
SET_SOURCE_FILES_PROPERTIES(${CMAKE_CURRENT_SOURCE_DIR}/cmakesrc/MadX.icns
PROPERTIES MACOSX_PACKAGE_LOCATION Resources)
endif(APPLE)
add_executable(madx${BINARY_POSTFIX} MACOSX_BUNDLE ${srcfiles})
SET_TARGET_PROPERTIES(madx${BINARY_POSTFIX} PROPERTIES LINKER_LANGUAGE
Fortran)
...
FIND_PACKAGE(X11)
IF(X11_FOUND)
message(Found X11 libraries)
INCLUDE_DIRECTORIES(${X11_INCLUDE_DIR})
TARGET_LINK_LIBRARIES(madx${BINARY_POSTFIX} ${X11_X11_LIB})
ENDIF(X11_FOUND)
...
target_link_libraries(madx${BINARY_POSTFIX} z)
target_link_libraries(madx${BINARY_POSTFIX} pthread)
target_link_libraries(madx${BINARY_POSTFIX} c)
target_link_libraries(madx${BINARY_POSTFIX} gcc_eh)
...
if(APPLE)
set(APPS \${CMAKE_INSTALL_PREFIX}/madx${BINARY_POSTFIX}.app) # paths to
executables
set(DIRS )
message(aps: ${APPS})
INSTALL(CODE
include(BundleUtilities)
message(\aps: ${APPS}\)
fixup_bundle(\${APPS}\ \\ \${DIRS}\)
COMPONENT Runtime)
INSTALL(TARGETS madx${BINARY_POSTFIX}
BUNDLE DESTINATION . COMPONENT Runtime
RUNTIME DESTINATION bin COMPONENT Runtime
)
else(APPLE)
INSTALL(TARGETS madx${BINARY_POSTFIX}
RUNTIME DESTINATION bin
LIBRARY DESTINATION lib
ARCHIVE DESTINATION lib
)
endif(APPLE)
...
# so that we can build dragndrop on osx (actually needed?):
set(CPACK_BINARY_DRAGNDROP ON)
include (CPack)
...
What I don't understand is why it does not work on my own project. From what
I can see you can actually replace the fixup_bundle() in the example with
simply fixup_bundle(\${APPS}\ \\ \\). This still gives the following
result when I check the binary with otools:
otool -L
_CPack_Packages/Darwin/DragNDrop/QtTest-0.1.1-Darwin/QtTest.app/Contents/MacOS/QtTest
_CPack_Packages/Darwin/DragNDrop/QtTest-0.1.1-Darwin/QtTest.app/Contents/MacOS/QtTest:
@executable_path/../Frameworks/QtGui.framework/Versions/4/QtGui
(compatibility version 4.7.0, current version 4.7.0)
@executable_path/../Frameworks/QtCore.framework/Versions/4/QtCore
(compatibility version 4.7.0, current version 4.7.0)
@executable_path/../MacOS/libstdc++.6.dylib (compatibility version 7.0.0,
current version 7.13.0)
@executable_path/../MacOS/libgcc_s.1.dylib (compatibility version 1.0.0,
current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
125.2.1)
The original shows:
otool -L QtTest.app/Contents/MacOS/QtTest
QtTest.app/Contents/MacOS/QtTest:
/opt/local/libexec/qt4-mac-devel/lib/QtGui.framework/Versions/4/QtGui
(compatibility version 4.7.0, current version 4.7.0)
/opt/local/libexec/qt4-mac-devel/lib/QtCore.framework/Versions/4/QtCore
(compatibility version 4.7.0, current version 4.7.0)
/opt/local/lib/gcc44/libstdc++.6.dylib (compatibility version 7.0.0,
current version 7.13.0)
/opt/local/lib/gcc44/libgcc_s.1.dylib (compatibility version 1.0.0,
Re: [CMake] How to assign data from subexpressions of regular expressions to CMake variables?
On Thu, Jan 20, 2011 at 02:06:33PM +0100, Michael Wild wrote: Ah, yes. I keep forgetting. Might I propose that the documentation about regular expressions be extracted into its own section and then be referenced from all commands that have a REGEX mode? Because, confusingly, the only documentation about regular expression is at the end of the string(REGEX REPLACE) command, but then uses if(... MATCHES ...) as an example. For the reader of the if( MATCHES ) documentation, this isn't very discoverable, it doesn't even refer him to the string(REGEX REPLACE) command. Not that I'm signing up for this job, but +1 on this suggestion. tyler ___ 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] How to query compiler definitions?
When you have such different levels of option you may do something like: OPTION(DEVELOPER_OPT_ENABLE Enable developer options OFF) OPTION(SYSTEM_INTEGRATOR_OPT_ENABLE Enable system integrator specific options OFF) OPTION(TOOL_USERS_OPT_ENABLE Enable tool users options ON) - software developers - system integrators - tool users then you do IF (DEVELOPER_OPT_ENABLE) OPTION(DEV_OPT1 blah blah ON) OPTION(DEV_OPT2 blah blah OFF) ENDIF(DEVELOPER_OPT_ENABLE) IF (TOOL_USERS_OPT_ENABLE) OPTION(USR_OPT1 blah blah ON) OPTION(USR_OPT2 blah blah OFF) OPTION(USR_OPT3 blah blah ON) ENDIF(TOOL_USERS_OPT_ENABLE) so an option may perfectly depend on another option, such kind of config may need several configure steps but its works well (at least for me). Sounds like you are searching for CMakeDependentOption. Search again in the man page an you will find it ;) Eike ___ 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] add_custom_target and Code Blocks generator
On Thursday 20 January 2011, Dimitri Kaparis wrote: On Thu, Jan 20, 2011 at 7:27 PM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: On Thursday 20 January 2011, Dimitri Kaparis wrote: Greetings, the Code Blocks generator is not adding to the project the sources, specified in the command. In order to add a group of header files to my project tree, I'm trying to implement the solution posted here: http://www.cmake.org/pipermail/cmake/2010-November/040537.html The target itself is added to the Code Blocks project, however the source files are not. Should I file a bug report? Are there any other workarounds for that use case, besides adding the headers to some other existing executable or library target? This is under linux, with CMake release 2.8.3. add_custom_target() does not have a list of source files. Which behaviour do you expect ? Can you post a small example CMakeLists.txt and explain what you would expect ? From the documentation at http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:add_custom_targ et The SOURCES option specifies additional source files to be included in the custom target. Specified source files will be added to IDE project files for convenience in editing even if they have not build rules. Ah, I didn't know that. http://public.kitware.com/Bug/view.php?id=11736 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
[CMake] Any way to make/fake subdirectories depending on ExternalProject?
I kinda know the simple answer is 'no.' I hope there's a creative *couch*sneaky*cough* way to do this. I'm trying to build CableSwig as a external project as part of ITK. I have this working for a single-process build. It works in that case because the ExternalProject_add happens textually before all the add_subdirectory clauses at the bottom of ITK's top level CMakeLists.txt file. If you run a parallel build, CableSwig gets downloaded and built in parallel with subdirectories that need CableSwig to build, so the compile fails, obviously. The problem is that subdirectories aren't targets, and can't depend on CableSwig. What I need is a trick to fake out CMake such that it guarantees the CableSwig subproject get built completely before moving on into subdirectories. Any ideas? Or am I just abusing the very spirit of 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
Re: [CMake] Any way to make/fake subdirectories depending on ExternalProject?
On 1/20/2011 3:19 PM, kent williams wrote: I kinda know the simple answer is 'no.' I hope there's a creative *couch*sneaky*cough* way to do this. I'm trying to build CableSwig as a external project as part of ITK. I have this working for a single-process build. It works in that case because the ExternalProject_add happens textually before all the add_subdirectory clauses at the bottom of ITK's top level CMakeLists.txt file. If you run a parallel build, CableSwig gets downloaded and built in parallel with subdirectories that need CableSwig to build, so the compile fails, obviously. The problem is that subdirectories aren't targets, and can't depend on CableSwig. What I need is a trick to fake out CMake such that it guarantees the CableSwig subproject get built completely before moving on into subdirectories. Any ideas? Or am I just abusing the very spirit of CMake? You are abusing the spirit of external project. To do this you would want to create one project that has two external projects: CableSwig ITK Then you can have ITK depend on CableSwig. You really can not mix external project with regular targets that expect that stuff to be built first. -Bill ___ 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] How to make a ProjectConfig.cmake
On 01/20/2011 01:36 PM, Alexander Neundorf wrote: On Thursday 20 January 2011, Brad King wrote: This all has been documented on the Wiki for years: http://www.cmake.org/Wiki/CMake_2.6_Notes It is more of a tutorial/reference format than an example/template though. Yes, it's just hard to find under the link CMake 2.6 Notes when looking for information on how to create a Config-file. I've re-organized the pages a bit to address this. See if you can find it starting here: http://www.cmake.org/Wiki/CMake#Basic_Introductions -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://www.cmake.org/mailman/listinfo/cmake
[CMake] continuous builds and CTEST_ELAPSED_TIME
hello cmakers,
i've been parsing some of the documentation/posts etc on continuous
builds. it seems a pretty common pattern for people to settle on a while
loop such as the one described in the official wiki
(http://www.cmake.org/Wiki/CMake_Scripting_Of_CTest):
while (${CTEST_ELAPSED_TIME} LESS 36000)
set (START_TIME ${CTEST_ELAPSED_TIME})
ctest_start (Continuous)
ctest_sleep( ${START_TIME} 300 ${CTEST_ELAPSED_TIME})
endwhile()
the bit i fail to understand is why is 36000 deemed as a good value
rather than ~86400? or is this because a lot of people have copied and
pasted from the wiki page? :-)
thanks for your time
marco
--
Constraint has encouraged not only economy, but also a certain elegance
of design. -- Dennis Ritchie
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] Any way to make/fake subdirectories depending on ExternalProject?
On Thursday 20 January 2011, Bill Hoffman wrote: On 1/20/2011 3:19 PM, kent williams wrote: I kinda know the simple answer is 'no.' I hope there's a creative *couch*sneaky*cough* way to do this. I'm trying to build CableSwig as a external project as part of ITK. I have this working for a single-process build. It works in that case because the ExternalProject_add happens textually before all the add_subdirectory clauses at the bottom of ITK's top level CMakeLists.txt file. If you run a parallel build, CableSwig gets downloaded and built in parallel with subdirectories that need CableSwig to build, so the compile fails, obviously. The problem is that subdirectories aren't targets, and can't depend on CableSwig. What I need is a trick to fake out CMake such that it guarantees the CableSwig subproject get built completely before moving on into subdirectories. Any ideas? Or am I just abusing the very spirit of CMake? You are abusing the spirit of external project. To do this you would want to create one project that has two external projects: CableSwig ITK Then you can have ITK depend on CableSwig. You really can not mix external project with regular targets that expect that stuff to be built first. Sure ? I do that at work without problems. The externalproject_add() creates targets using add_custom_target(), and I make my actual library/executable targets depend on these targets using add_dependencies(). 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] How to assign data from subexpressions of regular expressions to CMake variables?
On 20.01.2011, at 18:37, Alexander Neundorf a.neundorf-w...@gmx.net wrote: On Thursday 20 January 2011, Michael Wild wrote: On 01/20/2011 02:14 PM, David Cole wrote: ... Me too. I had to go searching for CMAKE_MATCH_ because I knew it was stated somewhere. Much to my surprise, there was only a single CMAKE_MATCH on our whole documentation page. It would make sense to document the variables CMAKE_MATCH_0 and friends explicitly. And cross-referencing left, right, north and south would also be good. You can propose all you want. I keep getting distracted by the real bugs on my plate... :-) ;-) Right. Anyways, some newbie doing serious RTFM as he should will stumble across the string(REGEX REPLACE) documentation any ways and connect the dots :-P I think Dave meant Please write a patch which adds the documentation and put this in the bugtracker :-) Alexy I know... What I meant was: neither do I have the time or the motivation, so people should cope themselves. :-P ___ 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] continuous builds and CTEST_ELAPSED_TIME
On Thu, Jan 20, 2011 at 08:38:41PM +, Marco Craveiro wrote: the bit i fail to understand is why is 36000 deemed as a good value rather than ~86400? or is this because a lot of people have copied and pasted from the wiki page? :-) Since the examples come from scripts Kitware uses in production, my guess to the origin of 10 hours is that this time period was useful for Kitware's specific circumstances. As to why everyone uses that number, I think your guess is exactly right. tyler ___ 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] How to query compiler definitions?
2011/1/20 Rolf Eike Beer e...@sf-mail.de: When you have such different levels of option you may do something like: OPTION(DEVELOPER_OPT_ENABLE Enable developer options OFF) OPTION(SYSTEM_INTEGRATOR_OPT_ENABLE Enable system integrator specific options OFF) OPTION(TOOL_USERS_OPT_ENABLE Enable tool users options ON) - software developers - system integrators - tool users then you do IF (DEVELOPER_OPT_ENABLE) OPTION(DEV_OPT1 blah blah ON) OPTION(DEV_OPT2 blah blah OFF) ENDIF(DEVELOPER_OPT_ENABLE) IF (TOOL_USERS_OPT_ENABLE) OPTION(USR_OPT1 blah blah ON) OPTION(USR_OPT2 blah blah OFF) OPTION(USR_OPT3 blah blah ON) ENDIF(TOOL_USERS_OPT_ENABLE) so an option may perfectly depend on another option, such kind of config may need several configure steps but its works well (at least for me). Sounds like you are searching for CMakeDependentOption. Search again in the man page an you will find it ;) Thank you Rolf I didn't realized it already exists and never dare looking for it since I was doint this by hand :-] Will use it next time. -- Erk Membre de l'April - « promouvoir et défendre le logiciel libre » - http://www.april.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] VS2010 tries to compile a file with *.res extension when its copied
I know I've asked this before, but now I've narrowed it down a bit and I
have an example. This copies a *.res file to the binary directory where
presumably the executable can find it. The executable has that file as a
source file to hook up the dependency, and the copied file has the
HEADER_FILE_ONLY property set. Yet, somehow VS2010 is still trying to
compile en.res. I even tried setting the source and destination en.res
files to HEADER_FILE_ONLY, but that didn't fix it. Removing the
ADD_CUSTOM_COMMAND that does the copy fixes the problem. Why is this
broken? FYI, it worked fine in VS2008.
CMAKE_MINIMUM_REQUIRED(VERSION 2.8)
PROJECT(cmake_res_bug)
SET(RESOURCE_FILE ${PROJECT_SOURCE_DIR}/resources/en.res)
GET_FILENAME_COMPONENT(RESOURCE_FILE_BASENAME ${RESOURCE_FILE} NAME)
SET(LOCAL_RESOURCE_FILE
${PROJECT_BINARY_DIR}/resources/${RESOURCE_FILE_BASENAME})
ADD_CUSTOM_COMMAND(
OUTPUT ${PROJECT_BINARY_DIR}/resources/${RESOURCE_FILE_BASENAME}
COMMAND ${CMAKE_COMMAND} -E make_directory
${PROJECT_BINARY_DIR}/resources
COMMAND ${CMAKE_COMMAND} -E copy ${RESOURCE_FILE}
${PROJECT_BINARY_DIR}/resources
DEPENDS ${RESOURCE_FILE}
COMMENT Localizing ${RESOURCE_FILE_BASENAME})
SET_SOURCE_FILES_PROPERTIES(
${LOCAL_RESOURCE_FILE}
PROPERTIES HEADER_FILE_ONLY TRUE)
INCLUDE_DIRECTORIES(${PROJECT_BINARY_DIR})
ADD_EXECUTABLE(
${PROJECT_NAME}
${PROJECT_SOURCE_DIR}/src/main.cpp
${LOCAL_RESOURCE_FILE})
---
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
Re: [CMake] CHECK_INCLUDE_FILES ignores CMAKE_FIND_ROOT_PATH, but should it?
Hi Alexander,
Thanks for your reply.
2011/1/20 Alexander Neundorf a.neundorf-w...@gmx.net:
On Monday 10 January 2011, Bjørn Forsman wrote:
Hi all,
I just found out that CHECK_INCLUDE_FILES ignores CMAKE_FIND_ROOT_PATH. The
documentation for CHECK_INCLUDE_FILES says:
...
The following variables may be set before calling this macro to
modify the way the check is run:
CMAKE_REQUIRED_FLAGS = string of compile command line flags
CMAKE_REQUIRED_DEFINITIONS = list of macros to define (-DFOO=bar)
CMAKE_REQUIRED_INCLUDES = list of include directories
So it seems intentional. But wouldn't it make sense to let
CHECK_INCLUDE_FILES look in CMAKE_FIND_ROOT_PATH? Or maybe more precise,
give the compiler include flags for
CMAKE_FIND_ROOT_PATH/{include/,usr/include}? It just seems wrong to me that
include files in CMAKE_FIND_ROOT_PATH can be ignored like that and it
destroys the meaning of CMAKE_FIND_ROOT_PATH. Comments?
Is maybe CHECK_INCLUDE_FILES deprecated and FIND_PATH/FIND_FILE is the way
to go?
check_include_files() is there to check whether header files in the compilers
system include path exist, i.e. which are found without any -I switches.
So, from that POV, the behaviour is ok.
Aha, so software using check_include_files() to look for *external*
packages/libraries _are doing it wrong_?
But I don't understand the use case for check_include_files(). When
would you want to limit yourself to only system include paths?
Can I actually tell the compiler/gcc to ignore its standard include dirs ?
AFAIK, GCC supports this. From 'man gcc':
--sysroot=dir
Use dir as the logical root directory for headers and
libraries. For example, if the
compiler would normally search for headers in /usr/include
and libraries in /usr/lib, it
will instead search dir/usr/include and dir/usr/lib.
What header files are you testing ?
From libc or from some other library ?
The cdrkit package uses check_include_files() on at least
sys/capability.h, from libcap. And libcap is an external library. So I
guess the right thing would be to patch cdrkit?
Best regards,
Bjørn Forsman
___
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] Restrictions on where a binary can be put?
On 01/20/2011 07:01 PM, Alexander Neundorf wrote:
On Sunday 09 January 2011, Michael Hertling wrote:
On 01/09/2011 09:47 PM, Nizar Khalifa Sallem wrote:
At Sun, 09 Jan 2011 21:42:49 +0100,
Michael Hertling wrote:
On 01/09/2011 09:09 PM, Andreas Pakulat wrote:
On 09.01.11 21:05:21, Andreas Pakulat wrote:
On 09.01.11 14:24:16, Michael Hertling wrote:
On 01/09/2011 12:58 PM, Andreas Pakulat wrote:
Hi,
I'm having a bit of a problem here changing the runtime output
directory for a binary. Its an executable target named 'setup' and
I'd like to put it into the top-level directory. Unfortunately it
always ends up in the bin/ directory, which is what
CMAKE_RUNTIME_OUTPUT_DIRECTORY is being set to.
I'm using
set_target_properties( setup PROPERTIES RUNTIME_OUTPUT_DIRECTORY
${CMAKE_BINARY_DIR} ) after creating the target currently, which
should work as far as I can see from the documentation. Are there
maybe any restrictions on what the directory may be or what targets
can be put there?
If not, any suggestions how to debug this? I can see that the
build.make does already have the rule setup for putting the binary
into bin/, so it must be going wrong somewhere in the generation
stage, but a simple cmake --trace doesn't show up anything
suspicious. Is there a switch to follow the steps that cmake does
during makefile-generation?
Could you provide a minimal but complete example?
Ok, attached case produces the error. Apparently the problem is
fetching the LOCATION property from the target and setting the
RUNTIME_OUTPUT_DIRECTORY afterwards. Looks like a cmake bug to me, so
I'll file a report.
Ooops, forgot the attachment :)
Now, I can confirm the issue; indeed, the GET_TARGET_PROPERTY() on the
LOCATION apparently renders the following SET_TARGET_PROPERTY() on the
RUNTIME_OUTPUT_DIRECTORY ineffective. As I cannot see any reason for
this, I'd agree that it should be considered as a bug. Besides, my
example was pointless: A simple clash of an executable main with
a subdirectory of the same name in CMAKE_BINARY_DIR, sorry. :/
Regards,
Michael
I don't really understand why you want to get the LOCATION from your
target, anyway, the get_target_property works fine if you use
set_target_properties before it. [...]
...but SET_TARGET_PROPERTIES() doesn't work fine if it's used after
GET_TARGET_PROPERTY(), even if both operate on different properties.
Well, they are not completely different.
If I remember correctly, the LOCATION property is calculcated when you
query
it. I think it changes some internal variables. Apparently to a state where
setting the target property afterwards doesn't have the desired effect
anymore :-/
So, what's your conclusion in this matter? Should the behavior in
question be considered as a bug or is it alright? IMO, such a subtle
side effect of a read operation on a subsequent write operation is at
least highly surprising. Besides, does one have to take this phenomenon
into account elsewhere, i.e. when saying
GET_TARGET_PROPERTY(VAR TARGET X)
...
SET_TARGET_PROPERTIES(TARGET PROPERTIES Y ...)
with X!=LOCATION and Y!=RUNTIME_OUTPUT_DIRECTORY, is it assured that
the latter command works as expected? Are directory or source files
properties possibly affected, too?
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
Re: [CMake] An issue with snow leopard?
Hi,
I had the same problem as OP. To fix, delete CMakeCache.txt in the build
dir, and run ccmake again. Phew!
BTW, is there a way to reply directly to an archived post? I just copied
the thread and subject into a new email msg, which is easy enough
actually.
Cheers,
Michael
===
Michael Wild
Sun Aug 30 04:41:04 EDT 2009
$ grep -r Wno-long-double cmake-2.6.4
cmake-2.6.4/Utilities/cmcurl/CMakeLists.txt: CHECK_C_COMPILER_FLAG(-
Wno-long-double HAVE_C_FLAG_Wno_long_double)
cmake-2.6.4/Utilities/cmcurl/CMakeLists.txt:
SET(MPRINTF_COMPILE_FLAGS ${MPRINTF_COMPILE_FLAGS} -Wno-long-double)
cmake-2.6.4/Utilities/cmcurl/CMakeLists.txt:
SET(MPRINTF_COMPILE_FLAGS -Wno-long-double)
As you can see, -Wno-long-double only shows up in the code that
compiles the Curl library, and that only if the flag is accepted by
the compiler (as you can see from the CHECK_C_COMPILER_FLAG). So I
suspect that this flag is set somewhere in your own CMake code.
Michael
On 29. Aug, 2009, at 19:30, Wei Lu wrote:
Hi Michael,
I removed the project and then recompiled (even rebuild cmake), but
it still appears the same error. I also attached a compiling log,
hope it can help.
Thanks,
Wei
compiling log.txt
On Aug 29, 2009, at 4:56 AM, Michael Wild wrote:
On 29. Aug, 2009, at 8:23, Wei Lu wrote:
Hi cmake users,
When I upgrade my mac to snow leopard, some of my projects don't
compile any more with cmake.
The error message is:
cc1plus: error: unrecognized command line option -Wno-long-double
My guess is that the option -Wno-long-double generated by cmake
is deprecated in snow leopard, am I right? How can I fix it?
Thanks,
Wei Lu
Are you sure CMake added this flag (I strongly doubt it)? Did you
try with a clean cache?
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
Re: [CMake] VS2010 tries to compile a file with *.res extension when its copied
Is tha with 2.8.3 or 2.8.4-rc1?
On Thursday, January 20, 2011, aaron_wri...@selinc.com wrote:
I know I've asked this before, but now I've narrowed it down a bit and I
have an example. This copies a *.res file to the binary directory where
presumably the executable can find it. The executable has that file as a
source file to hook up the dependency, and the copied file has the
HEADER_FILE_ONLY property set. Yet, somehow VS2010 is still trying to
compile en.res. I even tried setting the source and destination en.res
files to HEADER_FILE_ONLY, but that didn't fix it. Removing the
ADD_CUSTOM_COMMAND that does the copy fixes the problem. Why is this
broken? FYI, it worked fine in VS2008.
CMAKE_MINIMUM_REQUIRED(VERSION 2.8)
PROJECT(cmake_res_bug)
SET(RESOURCE_FILE ${PROJECT_SOURCE_DIR}/resources/en.res)
GET_FILENAME_COMPONENT(RESOURCE_FILE_BASENAME ${RESOURCE_FILE} NAME)
SET(LOCAL_RESOURCE_FILE
${PROJECT_BINARY_DIR}/resources/${RESOURCE_FILE_BASENAME})
ADD_CUSTOM_COMMAND(
OUTPUT ${PROJECT_BINARY_DIR}/resources/${RESOURCE_FILE_BASENAME}
COMMAND ${CMAKE_COMMAND} -E make_directory
${PROJECT_BINARY_DIR}/resources
COMMAND ${CMAKE_COMMAND} -E copy ${RESOURCE_FILE}
${PROJECT_BINARY_DIR}/resources
DEPENDS ${RESOURCE_FILE}
COMMENT Localizing ${RESOURCE_FILE_BASENAME})
SET_SOURCE_FILES_PROPERTIES(
${LOCAL_RESOURCE_FILE}
PROPERTIES HEADER_FILE_ONLY TRUE)
INCLUDE_DIRECTORIES(${PROJECT_BINARY_DIR})
ADD_EXECUTABLE(
${PROJECT_NAME}
${PROJECT_SOURCE_DIR}/src/main.cpp
${LOCAL_RESOURCE_FILE})
---
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
___
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] How to make a ProjectConfig.cmake
Am Donnerstag, den 20.01.2011, 15:36 -0500 schrieb Brad King: On 01/20/2011 01:36 PM, Alexander Neundorf wrote: On Thursday 20 January 2011, Brad King wrote: This all has been documented on the Wiki for years: http://www.cmake.org/Wiki/CMake_2.6_Notes It is more of a tutorial/reference format than an example/template though. Yes, it's just hard to find under the link CMake 2.6 Notes when looking for information on how to create a Config-file. I've re-organized the pages a bit to address this. See if you can find it starting here: http://www.cmake.org/Wiki/CMake#Basic_Introductions Impossible. What is the headline now? Micha ___ 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] CHECK_INCLUDE_FILES ignores CMAKE_FIND_ROOT_PATH, but should it?
2011/1/20 Alexander Neundorf a.neundorf-w...@gmx.net: check_include_files() is there to check whether header files in the compilers system include path exist, i.e. which are found without any -I switches. So, from that POV, the behaviour is ok. Aha, so software using check_include_files() to look for *external* packages/libraries _are doing it wrong_? But I don't understand the use case for check_include_files(). When would you want to limit yourself to only system include paths? E.g. to check if stdint.h, unistd.h or io.h exists when you are supporting platforms like Windows and Linux. Can I actually tell the compiler/gcc to ignore its standard include dirs ? AFAIK, GCC supports this. From 'man gcc': --sysroot=dir Use dir as the logical root directory for headers and libraries. For example, if the compiler would normally search for headers in /usr/include and libraries in /usr/lib, it will instead search dir/usr/include and dir/usr/lib. What header files are you testing ? From libc or from some other library ? The cdrkit package uses check_include_files() on at least sys/capability.h, from libcap. And libcap is an external library. So I guess the right thing would be to patch cdrkit? Uh, don't know. Maybe FIND_PATH or FIND_FILE? Eike ___ 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] Restrictions on where a binary can be put?
On 21.01.11 01:37:41, Michael Hertling wrote: So, what's your conclusion in this matter? Should the behavior in question be considered as a bug or is it alright? IMO, such a subtle side effect of a read operation on a subsequent write operation is at least highly surprising. Besides, does one have to take this phenomenon into account elsewhere, i.e. when saying GET_TARGET_PROPERTY(VAR TARGET X) ... SET_TARGET_PROPERTIES(TARGET PROPERTIES Y ...) with X!=LOCATION and Y!=RUNTIME_OUTPUT_DIRECTORY, is it assured that the latter command works as expected? Are directory or source files properties possibly affected, too? Check the bugreport I mentioned further up in the thread. The docs have been expanded to mention this problem with LOCATION and RUNTIME_OUTPUT_DIRECTORY. As far as I understood Brad in the report its unique to those properties defining where a target ends up on disk (and how). And indeed (as he said also) changing the output directory _after_ querying it (via LOCATION) hints towards a bug in your cmake code, after all whatever you did with LOCATION is void if you change the output directory again and you'd have to re-run that code. Andreas -- Don't read everything you believe. ___ 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-commits] CMake branch, next, updated. v2.8.3-1437-g0aadafa
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via 0aadafa069824f107fa68a875c97e778c3cf1c98 (commit) via 1c8787f387e9958e5ca4a9e5d268bb942966305f (commit) from 18e07843c8416590c0cb444e8936a709d4a93862 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0aadafa069824f107fa68a875c97e778c3cf1c98 commit 0aadafa069824f107fa68a875c97e778c3cf1c98 Merge: 18e0784 1c8787f Author: Brad King brad.k...@kitware.com AuthorDate: Thu Jan 20 07:23:19 2011 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Thu Jan 20 07:23:19 2011 -0500 Merge branch 'master' into next --- Summary of changes: Source/kwsys/kwsysDateStamp.cmake |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.3-1440-g52a7852
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via 52a78520f853c6f2ffee2c41bc2d7bfb05fd54fe (commit) via a5300f1d450daaac7d9a421710141897af304c45 (commit) via a146e03422dcfaa6df6dc2f5ce594862126b17ef (commit) from 0aadafa069824f107fa68a875c97e778c3cf1c98 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=52a78520f853c6f2ffee2c41bc2d7bfb05fd54fe commit 52a78520f853c6f2ffee2c41bc2d7bfb05fd54fe Merge: 0aadafa a5300f1 Author: Brad King brad.k...@kitware.com AuthorDate: Thu Jan 20 07:45:36 2011 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Thu Jan 20 07:45:36 2011 -0500 Merge topic 'relative-CMAKE_USER_MAKE_RULES_OVERRIDE' into next a5300f1 Clarify CMAKE_USER_MAKE_RULES_OVERRIDE documentation (#11724) a146e03 Fix relative CMAKE_USER_MAKE_RULES_OVERRIDE (#11725) diff --cc Source/cmDocumentVariables.cxx index e9b54d8,40d416f..6fffecb --- a/Source/cmDocumentVariables.cxx +++ b/Source/cmDocumentVariables.cxx @@@ -696,15 -625,31 +696,31 @@@ void cmDocumentVariables::DefineVariabl cm-DefineProperty (CMAKE_USER_MAKE_RULES_OVERRIDE, cmProperty::VARIABLE, - Specify a file that can change the build rule variables., - If this variable is set, it should to point to a - CMakeLists.txt file that will be read in by CMake - after all the system settings have been set, but - before they have been used. This would allow you - to override any variables that need to be changed - for some special project. ,false, + Specify a CMake file that overrides platform information., + CMake loads the specified file while enabling support for each + language from either the project() or enable_language() commands. + It is loaded after CMake's builtin compiler and platform information + modules have been loaded but before the information is used. + The file may set platform information variables to override CMake's + defaults. + \n + This feature is intended for use only in overriding information + variables that must be set before CMake builds its first test + project to check that the compiler for a language works. + It should not be used to load a file in cases that a normal include() + will work. + Use it only as a last resort for behavior that cannot be achieved + any other way. + For example, one may set CMAKE_C_FLAGS_INIT to change the default + value used to initialize CMAKE_C_FLAGS before it is cached. + The override file should NOT be used to set anything that could + be set after languages are enabled, such as variables like + CMAKE_RUNTIME_OUTPUT_DIRECTORY that affect the placement of binaries. + Information set in the file will be used for try_compile and try_run + builds too. + ,false, Variables That Change Behavior); - + cm-DefineProperty (BUILD_SHARED_LIBS, cmProperty::VARIABLE, Global flag to cause add_library to create shared libraries if on., http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=a5300f1d450daaac7d9a421710141897af304c45 commit a5300f1d450daaac7d9a421710141897af304c45 Author: Brad King brad.k...@kitware.com AuthorDate: Thu Jan 20 07:35:00 2011 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Thu Jan 20 07:35:00 2011 -0500 Clarify CMAKE_USER_MAKE_RULES_OVERRIDE documentation (#11724) This variable was introduced to help authors override CMake's default platform information before any of it is cached. State this clearly in the documentation. Explicitly discourage use for other purposes. diff --git a/Source/cmDocumentVariables.cxx b/Source/cmDocumentVariables.cxx index 2ed959f..40d416f 100644 --- a/Source/cmDocumentVariables.cxx +++ b/Source/cmDocumentVariables.cxx @@ -625,13 +625,29 @@ void cmDocumentVariables::DefineVariables(cmake* cm) cm-DefineProperty (CMAKE_USER_MAKE_RULES_OVERRIDE, cmProperty::VARIABLE, - Specify a file that can change the build rule variables., - If this variable is set, it should to point to a - CMakeLists.txt file that will be read in by CMake - after all the system settings have been set, but - before they have been used. This would allow you - to override any variables that need to be changed - for some special project. ,false, + Specify a CMake file that overrides platform information., + CMake loads the specified file while enabling support for each + language from either the project() or enable_language()
[Cmake-commits] CMake branch, next, updated. v2.8.3-1444-g2acfb25
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 2acfb25d43264514ae3712375b2543e57bf57414 (commit)
via 1bee6b172bdeb4c02cafbc98d162e8d2cfd5c53f (commit)
from 2418073e0f591d445d564537246f55ffa5641172 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2acfb25d43264514ae3712375b2543e57bf57414
commit 2acfb25d43264514ae3712375b2543e57bf57414
Merge: 2418073 1bee6b1
Author: Brad King brad.k...@kitware.com
AuthorDate: Thu Jan 20 09:09:37 2011 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Jan 20 09:09:37 2011 -0500
Merge topic 'improve-try_compile-error-messages' into next
1bee6b1 Improve try_compile and try_run error messages
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=1bee6b172bdeb4c02cafbc98d162e8d2cfd5c53f
commit 1bee6b172bdeb4c02cafbc98d162e8d2cfd5c53f
Author: Brad King brad.k...@kitware.com
AuthorDate: Thu Jan 20 08:58:49 2011 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Thu Jan 20 08:58:49 2011 -0500
Improve try_compile and try_run error messages
Use IssueMessage to give the messages context and better formatting.
diff --git a/Source/cmCoreTryCompile.cxx b/Source/cmCoreTryCompile.cxx
index dab0c0d..0ea6c5e 100644
--- a/Source/cmCoreTryCompile.cxx
+++ b/Source/cmCoreTryCompile.cxx
@@ -1,6 +1,6 @@
/*
CMake - Cross Platform Makefile Generator
- Copyright 2000-2009 Kitware, Inc., Insight Software Consortium
+ Copyright 2000-2011 Kitware, Inc., Insight Software Consortium
Distributed under the OSI-approved BSD License (the License);
see accompanying file Copyright.txt for details.
@@ -56,7 +56,7 @@ int cmCoreTryCompile::TryCompileCode(std::vectorstd::string
const argv)
{
if ( argv.size() = (i+1) )
{
-cmSystemTools::Error(
+this-Makefile-IssueMessage(cmake::FATAL_ERROR,
OUTPUT_VARIABLE specified but there is no variable);
return -1;
}
@@ -92,7 +92,7 @@ int cmCoreTryCompile::TryCompileCode(std::vectorstd::string
const argv)
{
if ( argv.size() = (i+1) )
{
-cmSystemTools::Error(
+this-Makefile-IssueMessage(cmake::FATAL_ERROR,
COPY_FILE specified but there is no variable);
return -1;
}
@@ -120,13 +120,14 @@ int
cmCoreTryCompile::TryCompileCode(std::vectorstd::string const argv)
// only valid for srcfile signatures
if (compileFlags.size())
{
- cmSystemTools::Error(
+ this-Makefile-IssueMessage(cmake::FATAL_ERROR,
COMPILE_FLAGS specified on a srcdir type TRY_COMPILE);
return -1;
}
if (copyFile.size())
{
- cmSystemTools::Error(COPY_FILE specified on a srcdir type TRY_COMPILE);
+ this-Makefile-IssueMessage(cmake::FATAL_ERROR,
+COPY_FILE specified on a srcdir type TRY_COMPILE);
return -1;
}
}
@@ -136,9 +137,10 @@ int
cmCoreTryCompile::TryCompileCode(std::vectorstd::string const argv)
// do not allow recursive try Compiles
if (this-BinaryDirectory == this-Makefile-GetHomeOutputDirectory())
{
-cmSystemTools::Error(
- Attempt at a recursive or nested TRY_COMPILE in directory ,
- this-BinaryDirectory.c_str());
+cmOStringStream e;
+e Attempt at a recursive or nested TRY_COMPILE in directory\n
+ this-BinaryDirectory \n;
+this-Makefile-IssueMessage(cmake::FATAL_ERROR, e.str());
return -1;
}
@@ -158,9 +160,11 @@ int
cmCoreTryCompile::TryCompileCode(std::vectorstd::string const argv)
FILE *fout = fopen(outFileName.c_str(),w);
if (!fout)
{
- cmSystemTools::Error(Failed to create CMakeList file for ,
- outFileName.c_str());
- cmSystemTools::ReportLastSystemError();
+ cmOStringStream e;
+ e Failed to open\n
+ outFileName.c_str() \n
+ cmSystemTools::GetLastSystemError();
+ this-Makefile-IssueMessage(cmake::FATAL_ERROR, e.str());
return -1;
}
@@ -181,10 +185,12 @@ int
cmCoreTryCompile::TryCompileCode(std::vectorstd::string const argv)
}
else
{
+ fclose(fout);
cmOStringStream err;
- err Unknown extension \ ext \ for file \
- source \. TRY_COMPILE only works for enabled languages.\n
- Currently enabled languages are:;
+ err Unknown extension \ ext \ for file\n
+ source \n
+ try_compile() works only for enabled languages.
+ Currently these are:\n ;
[Cmake-commits] CMake branch, next, updated. v2.8.3-1446-g7e05f20
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via 7e05f2022b860b00c67d7e2fb930c52fe52a9f3a (commit) via 699a7255847ba8b348ba63a2244b5b57b328261c (commit) from 2acfb25d43264514ae3712375b2543e57bf57414 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=7e05f2022b860b00c67d7e2fb930c52fe52a9f3a commit 7e05f2022b860b00c67d7e2fb930c52fe52a9f3a Merge: 2acfb25 699a725 Author: Brad King brad.k...@kitware.com AuthorDate: Thu Jan 20 09:09:46 2011 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Thu Jan 20 09:09:46 2011 -0500 Merge topic 'fix-try_compile-source-language-issue-11731' into next 699a725 Use shortest extension to verify try_compile language (#11731) http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=699a7255847ba8b348ba63a2244b5b57b328261c commit 699a7255847ba8b348ba63a2244b5b57b328261c Author: Brad King brad.k...@kitware.com AuthorDate: Thu Jan 20 09:02:57 2011 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Thu Jan 20 09:02:57 2011 -0500 Use shortest extension to verify try_compile language (#11731) If the source-file form of try_compile is given a file name with multiple '.' characters such as a.b.c use only the shortest extension to check the language. This is the expected behavior and is consistent with normal language extension determination in the method cmSourceFileLocation::UpdateExtension. diff --git a/Source/cmCoreTryCompile.cxx b/Source/cmCoreTryCompile.cxx index 0ea6c5e..d636cb8 100644 --- a/Source/cmCoreTryCompile.cxx +++ b/Source/cmCoreTryCompile.cxx @@ -169,7 +169,7 @@ int cmCoreTryCompile::TryCompileCode(std::vectorstd::string const argv) } std::string source = argv[2]; -std::string ext = cmSystemTools::GetFilenameExtension(source); +std::string ext = cmSystemTools::GetFilenameLastExtension(source); const char* lang =(this-Makefile-GetCMakeInstance()-GetGlobalGenerator() -GetLanguageFromExtension(ext.c_str())); const char* def = this-Makefile-GetDefinition(CMAKE_MODULE_PATH); --- Summary of changes: Source/cmCoreTryCompile.cxx |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- CMake ___ Cmake-commits mailing list Cmake-commits@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.3-1448-g9efb320
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 9efb320e3bde9d080a8f4af33016a8354fba60df (commit)
via 4c1c358332e9dd2b9ec165450f64d3a542e3433a (commit)
from 7e05f2022b860b00c67d7e2fb930c52fe52a9f3a (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=9efb320e3bde9d080a8f4af33016a8354fba60df
commit 9efb320e3bde9d080a8f4af33016a8354fba60df
Merge: 7e05f20 4c1c358
Author: Brad King brad.k...@kitware.com
AuthorDate: Thu Jan 20 12:03:56 2011 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Jan 20 12:03:56 2011 -0500
Merge topic 'qt4-fphsa' into next
4c1c358 FindQt4: Include builtin FindPackageHandleStandardArgs directly
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=4c1c358332e9dd2b9ec165450f64d3a542e3433a
commit 4c1c358332e9dd2b9ec165450f64d3a542e3433a
Author: Brad King brad.k...@kitware.com
AuthorDate: Thu Jan 20 11:45:39 2011 -0500
Commit: Brad King brad.k...@kitware.com
CommitDate: Thu Jan 20 11:46:32 2011 -0500
FindQt4: Include builtin FindPackageHandleStandardArgs directly
Apply to FindQt4 change from commit b0118402 (Use absolute path to
FindPackageHandleStandardArgs.cmake everywhere, 2010-09-28).
diff --git a/Modules/FindQt4.cmake b/Modules/FindQt4.cmake
index 70e69b0..ec04cd2 100644
--- a/Modules/FindQt4.cmake
+++ b/Modules/FindQt4.cmake
@@ -354,7 +354,7 @@ ENDIF(QT_QT_LIBRARY)
INCLUDE(CheckSymbolExists)
INCLUDE(MacroAddFileDependencies)
-INCLUDE(FindPackageHandleStandardArgs)
+INCLUDE(${CMAKE_CURRENT_LIST_DIR}/FindPackageHandleStandardArgs.cmake)
SET(QT_USE_FILE ${CMAKE_ROOT}/Modules/UseQt4.cmake)
---
Summary of changes:
Modules/FindQt4.cmake |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
hooks/post-receive
--
CMake
___
Cmake-commits mailing list
Cmake-commits@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-commits
[Cmake-commits] CMake branch, next, updated. v2.8.3-1453-gad4e4f6
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project CMake. The branch, next has been updated via ad4e4f64662f5387b539edde5fd09231cab1b5b4 (commit) via 2c6d2ea6d0032ed2105103005cba89d6d8a2704e (commit) via c4275592a89c308d251a1de70e3ffc95916e (commit) from 5fcf347f53826b39920eda4675e3dbe2c139617e (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log - http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=ad4e4f64662f5387b539edde5fd09231cab1b5b4 commit ad4e4f64662f5387b539edde5fd09231cab1b5b4 Merge: 5fcf347 2c6d2ea Author: Brad King brad.k...@kitware.com AuthorDate: Thu Jan 20 12:04:21 2011 -0500 Commit: CMake Topic Stage kwro...@kitware.com CommitDate: Thu Jan 20 12:04:21 2011 -0500 Merge topic 'resolve/use-own-FindPackageHandleStandardArgs/multilingual-FindMPI' into next 2c6d2ea Merge branch 'multilingual-FindMPI' into resolve/use-own-FindPackageHandleStandardArgs/multilingual-FindMPI c427559 Modules: Include builtin FindPackageHandleStandardArgs directly http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2c6d2ea6d0032ed2105103005cba89d6d8a2704e commit 2c6d2ea6d0032ed2105103005cba89d6d8a2704e Merge: c427559 4b660ed Author: Brad King brad.k...@kitware.com AuthorDate: Thu Jan 20 11:54:03 2011 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Thu Jan 20 11:54:03 2011 -0500 Merge branch 'multilingual-FindMPI' into resolve/use-own-FindPackageHandleStandardArgs/multilingual-FindMPI Conflicts: Modules/FindMPI.cmake http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c4275592a89c308d251a1de70e3ffc95916e commit c4275592a89c308d251a1de70e3ffc95916e Author: Brad King brad.k...@kitware.com AuthorDate: Thu Jan 20 10:56:49 2011 -0500 Commit: Brad King brad.k...@kitware.com CommitDate: Thu Jan 20 10:56:49 2011 -0500 Modules: Include builtin FindPackageHandleStandardArgs directly The FindPackageHandleStandardArgs module was originally created outside of CMake. It was added for CMake 2.6.0 by commit e118a627 (add a macro FIND_PACKAGE_HANDLE_STANDARD_ARGS..., 2007-07-18). However, it also proliferated into a number of other projects that at the time required only CMake 2.4 and thus could not depend on CMake to provide the module. CMake's own find modules started using the module in commit b5f656e0 (use the new FIND_PACKAGE_HANDLE_STANDARD_ARGS in some of the FindXXX modules..., 2007-07-18). Then commit d358cf5c (add 2nd, more powerful mode to find_package_handle_standard_args, 2010-07-29) added a new feature to the interface of the module that was fully optional and backward compatible with all existing users of the module. Later commit 5f183caa (FindZLIB: use the FPHSA version mode, 2010-08-04) and others shortly thereafter started using the new interface in CMake's own find modules. This change was also backward compatible because it was only an implementation detail within each module. Unforutnately these changes introduced a problem for projects that still have an old copy of FindPackageHandleStandardArgs in CMAKE_MODULE_PATH. When any such project uses one of CMake's builtin find modules the line include(FindPackageHandleStandardArgs) loads the copy from the project which does not have the new interface! Then the including find module tries to use the new interface with the old module and fails. Whether this breakage can be considered a backward incompatible change in CMake is debatable. The situation is analagous to copying a standard library header from one version of a compiler into a project and then observing problems when the next version of the compiler reports errors in its other headers that depend on its new version of the original header. Nevertheless it is a change to CMake that causes problems for projects that worked with previous versions. This problem was discovered during the 2.8.3 release candidate cycle. It is an instance of a more general problem with projects that provide their own versions of CMake modules when other CMake modules depend on them. At the time we resolved this instance of the problem with commit b0118402 (Use absolute path to FindPackageHandleStandardArgs.cmake everywhere, 2010-09-28) for the 2.8.3 release. In order to address the more general problem we introduced policy CMP0017 in commit db44848f (Prefer files from CMAKE_ROOT when including from CMAKE_ROOT, 2010-11-17). That change was followed by commit ce28737c (Remove usage of CMAKE_CURRENT_LIST_DIR now that we have
[Cmake-commits] CMake branch, next, updated. v2.8.3-1457-g48f7f11
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project CMake.
The branch, next has been updated
via 48f7f1121be292e941ab1eb4f710e23ff9ac95a6 (commit)
via d94f9c6487b324e7453deff15c8968acba23d98f (commit)
via b6c302b1aac9d903e5904febcec0902605dacee2 (commit)
via 0594287606dad64904935901d5625b4f47d61ef6 (commit)
from ad4e4f64662f5387b539edde5fd09231cab1b5b4 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=48f7f1121be292e941ab1eb4f710e23ff9ac95a6
commit 48f7f1121be292e941ab1eb4f710e23ff9ac95a6
Merge: ad4e4f6 d94f9c6
Author: Ben Boeckel ben.boec...@kitware.com
AuthorDate: Thu Jan 20 14:09:26 2011 -0500
Commit: CMake Topic Stage kwro...@kitware.com
CommitDate: Thu Jan 20 14:09:26 2011 -0500
Merge topic 'dev/add_test-working-directory' into next
d94f9c6 Only set the property if the property was given
b6c302b Default the working dir to the current binary dir
0594287 Add more tests for WorkingDirectory for tests
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d94f9c6487b324e7453deff15c8968acba23d98f
commit d94f9c6487b324e7453deff15c8968acba23d98f
Author: Ben Boeckel ben.boec...@kitware.com
AuthorDate: Thu Jan 20 14:05:39 2011 -0500
Commit: Ben Boeckel ben.boec...@kitware.com
CommitDate: Thu Jan 20 14:05:39 2011 -0500
Only set the property if the property was given
diff --git a/Source/cmAddTestCommand.cxx b/Source/cmAddTestCommand.cxx
index 72a6e93..a9165f5 100644
--- a/Source/cmAddTestCommand.cxx
+++ b/Source/cmAddTestCommand.cxx
@@ -74,8 +74,7 @@ bool
cmAddTestCommand::HandleNameMode(std::vectorstd::string const args)
{
std::string name;
std::vectorstd::string configurations;
- std::string working_directory = this-Makefile-GetCurrentOutputDirectory();
- bool working_directory_set = false;
+ std::string working_directory;
std::vectorstd::string command;
// Read the arguments.
@@ -109,13 +108,12 @@ bool
cmAddTestCommand::HandleNameMode(std::vectorstd::string const args)
}
else if(args[i] == WORKING_DIRECTORY)
{
- if(working_directory_set)
+ if(!working_directory.empty())
{
this-SetError( may be given at most one WORKING_DIRECTORY.);
return false;
}
doing = DoingWorkingDirectory;
- working_directory_set = true;
}
else if(doing == DoingName)
{
@@ -172,7 +170,10 @@ bool
cmAddTestCommand::HandleNameMode(std::vectorstd::string const args)
cmTest* test = this-Makefile-CreateTest(name.c_str());
test-SetOldStyle(false);
test-SetCommand(command);
- test-SetProperty(WORKING_DIRECTORY, working_directory.c_str());
+ if(!working_directory.empty())
+{
+test-SetProperty(WORKING_DIRECTORY, working_directory.c_str());
+}
this-Makefile-AddTestGenerator(new cmTestGenerator(test, configurations));
return true;
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=b6c302b1aac9d903e5904febcec0902605dacee2
commit b6c302b1aac9d903e5904febcec0902605dacee2
Author: Ben Boeckel ben.boec...@kitware.com
AuthorDate: Thu Jan 20 13:52:42 2011 -0500
Commit: Ben Boeckel ben.boec...@kitware.com
CommitDate: Thu Jan 20 13:52:42 2011 -0500
Default the working dir to the current binary dir
Keep backwards compatability with CMake = 2.8.3.
diff --git a/Source/cmAddTestCommand.cxx b/Source/cmAddTestCommand.cxx
index 11ca9e7..72a6e93 100644
--- a/Source/cmAddTestCommand.cxx
+++ b/Source/cmAddTestCommand.cxx
@@ -74,7 +74,8 @@ bool
cmAddTestCommand::HandleNameMode(std::vectorstd::string const args)
{
std::string name;
std::vectorstd::string configurations;
- std::string working_directory;
+ std::string working_directory = this-Makefile-GetCurrentOutputDirectory();
+ bool working_directory_set = false;
std::vectorstd::string command;
// Read the arguments.
@@ -108,12 +109,13 @@ bool
cmAddTestCommand::HandleNameMode(std::vectorstd::string const args)
}
else if(args[i] == WORKING_DIRECTORY)
{
- if(!working_directory.empty())
+ if(working_directory_set)
{
this-SetError( may be given at most one WORKING_DIRECTORY.);
return false;
}
doing = DoingWorkingDirectory;
+ working_directory_set = true;
}
else if(doing == DoingName)
{
http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=0594287606dad64904935901d5625b4f47d61ef6
commit 0594287606dad64904935901d5625b4f47d61ef6
Author: Ben Boeckel ben.boec...@kitware.com
AuthorDate: Thu Jan 20 13:47:53 2011 -0500
Commit: Ben Boeckel ben.boec...@kitware.com
CommitDate: Thu Jan 20 13:47:53 2011 -0500
Add more tests
