[cmake-developers] VS2010 fortran composer
I've made some progress on a Fortran Composer generator for VS2010
If I create a fortran project, I can load it in the IDE and everything works
OK, but in order to do this I must detect the fortran compiler first. I am
doing this by running cmake using nmake makefiles, then changing the generator
in the cmakecach file manually to use the visual studio generator. All is well.
Now that the generator is producing projects that load and compile (very simple
ones). I wanted to make the cmTryCompileExec run using the project generator
from first iteration.
When I try it, I get the following.
C:\cmakebuild\fortrantest\CMakeFiles\CMakeTmp\cmTryCompileExec.vfproj(2,1):
error MSB4075: The project file
C:\cmakebuild\fortrantest\CMakeFiles\CMakeTmp\cmTryCompileExec.vfproj must be
opened in the Visual Studio IDE and converted to the latest version before it
can be built by MSBuild.
At this point, I'm not sure what to do.
Has anyone encountered this message before? (google is not helping much for me
yet). I wonder if there is some completely different format used by msbuild
rather than the devenv. The fortran projects look completely different to the
cxx ones. simple vfproj attached for your reference.
PS. the ProjectIdGuid={1693218C-E07A-4FC1-9D1C-7100019B3A95} is just copied
from a generated project. How should I set this?
JB
?xml version=1.0 encoding=UTF-8?
VisualStudioProject ProjectCreator=Intel Fortran Keyword=Console
Application Version=11.0
ProjectIdGuid={1693218C-E07A-4FC1-9D1C-7100019B3A95}
Platforms
Platform Name=x64/
/Platforms
Configurations
Configuration Name=Debug|x64
Tool Name=VFFortranCompilerTool SuppressStartupBanner=true
DebugInformationFormat=debugEnabled Optimization=optimizeDisabled
Interfaces=true WarnInterfaces=true Traceback=true BoundsCheck=true
RuntimeLibrary=rtMultiThreadedDebug/
Tool Name=VFLinkerTool LinkIncremental=linkIncrementalNo
SuppressStartupBanner=true GenerateDebugInformation=true
SubSystem=subSystemConsole/
Tool Name=VFResourceCompilerTool/
Tool Name=VFMidlTool SuppressStartupBanner=true
TargetEnvironment=midlTargetAMD64/
Tool Name=VFCustomBuildTool/
Tool Name=VFPreLinkEventTool/
Tool Name=VFPreBuildEventTool/
Tool Name=VFPostBuildEventTool/
Tool Name=VFManifestTool SuppressStartupBanner=true//Configuration
Configuration Name=Release|x64
Tool Name=VFFortranCompilerTool SuppressStartupBanner=true/
Tool Name=VFLinkerTool LinkIncremental=linkIncrementalNo
SuppressStartupBanner=true SubSystem=subSystemConsole/
Tool Name=VFResourceCompilerTool/
Tool Name=VFMidlTool SuppressStartupBanner=true
TargetEnvironment=midlTargetAMD64/
Tool Name=VFCustomBuildTool/
Tool Name=VFPreLinkEventTool/
Tool Name=VFPreBuildEventTool/
Tool Name=VFPostBuildEventTool/
Tool Name=VFManifestTool SuppressStartupBanner=true//Configuration
/Configurations
Files
Filter Name=Header Files Filter=fi;fd/
Filter Name=Resource Files
Filter=rc;ico;cur;bmp;dlg;rc2;rct;bin;rgs;gif;jpg;jpeg;jpe/
Filter Name=Source Files Filter=f90;for;f;fpp;ftn;def;odl;idl
File RelativePath=testFortranCompiler.f//Filter/Files
Globals//VisualStudioProject
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] [CMake] xcode project and static library dependencies
Nick,
We are using a modification on your patch internally.
Few things
1) It breaks projects that have resources. Fix is to attach the Executable
to only the 'copy to cmake build dir' phase. Even after the mailinglist
discussion I'm unsure of the need for this?
XCode basically claims it is a recursive dependency as the executable file
is added as a depenency on the Copy Files phase.
2) POST_BUILD targets stopped working. Re-added the code that uses those
(Before the copy-files target, maybe it should be after? I Really don't
understand the copy to cmake build dir phase.
Attached the original Patch from Nick modified to work with lastest git
master + two fixes mentioned above.
/Johan
On Sun, Feb 20, 2011 at 2:43 PM, Johan Björk p...@spotify.com wrote:
Hi Nick,
Any updates on this patch?
Cheers
/Johan
On Thu, Jan 20, 2011 at 2:08 AM, Nick Kledzik kled...@apple.com wrote:
BTW, it might make more sense to move this to the cmake-developers
mailing list.
I've transfered this thread to the developer list. See below for
continuation..
On Jan 18, 2011, at 12:42 PM, Bill Hoffman wrote:
On 1/18/2011 2:40 PM, Brad King wrote:
On 1/18/2011 2:12 PM, Nick Kledzik wrote:
When I use cmake to create a Makefile, the resulting main executable
is placed in the build directory tree next to the Makefile.
This is where CMake puts files in single-configuration generators.
When I use cmake to create a xcode project, the resulting main
executable is placed in a subdirectory named Debug of the build
directory tree.
This is where CMake puts files in multi-configuration generators.
Both of the above are expected default behaviors. Both can be
changed by CMake properties like RUNTIME_OUTPUT_DIRECTORY and
its per-configuration equivalent. All CMake generators must
honor these.
None of these locations are the native location
where Xcode would put a build result.
Xcode has settings like CONFIGURATION_BUILD_DIR to control
where the build outputs go. This already works. Is there
some reason your changes cannot use these?
My understanding is that the main problem with the current generator
is all the extra build phases and OTHER_LDFLAGS stuff used to deal
with link line ordering and static libraries. This is what Bill
summarized:
On 1/13/2011 3:41 PM, Bill Hoffman wrote:
- have a static library show up more than once on a link line
- be able to specify the order of static libraries on the link line
- be able to relink and executable when a static library that it
depends on is rebuilt.
I'm more interested in a solution to implementation issues like these
than in interface details like where output files go.
-Brad
So, for Xcode and VS IDE, CMake will place things in directories like
Debug, Release.
For example, you should get something like this:
${RUNTIME_OUTPUT_DIRECTORY}/Debug/myexe
Xcode does support building multiple configurations like Debug, Release,
etc. Where is the native location for those files?
As I said, it is per-user xcode settings. You cannot infer the location
from source tree cmake has access to.
At build time, the location is known within xcode. So, I added a
copy-file phase to have xocde copy the resulting binary from the native
location to the standard location the cmake expects. There is little
overhead for this.
I've now have a patch which:
1) preserves link order
2) builds libraries into the xcode native location
4) removes pre and post shell script phases previously used to fix
dependency problems
3) xcode projects now have proper dependencies
WIth this cmake patch, I can build CMake.xcodeproject, open it in xcode,
build-all, set the current target to be cmake, make a source change, hit
build, and have xcode just compile that one file, re-archive the library,
then re-link cmake tool. I also debugged all this in Xcode by setting
arguments for the cmake tool and hitting the build-and-debug within xcode!
Attached is the patch from cmake-2.8.3 sources:
This cmake also creates an xcode project that builds LLVM. It is still
not quite optimal because there are a bunch of cases where custom rules
cause a custom make file to be generated which is executed from within xcode
via a shell script phase. Xcode does not now which files the script might
modify, so xcode has to be conservative and re-check all timestamps. There
are ways to add custom scripts with specified input and output files in
xcode. I may get to fixing that someday...
How does one run the test suite? I saw the instructions about building
cmake for make, then executing make Experimental. I did that and all 184
or 184 tests passed. But it looks like this is running the cmake generated
makefiles - not cmake generated xcode projects.
-Nick
___
cmake-developers mailing list
cmake-developers@cmake.org
Re: [cmake-developers] [CMake] xcode project and static library dependencies
and wow, the patch I just sent is broken because cmXCodeObject-Print() has
sideffects! :(
Will send a patch that fixes -Print() when I have some extra time.
/Johan
On Mon, Mar 7, 2011 at 1:33 PM, Johan Björk p...@spotify.com wrote:
Nick,
We are using a modification on your patch internally.
Few things
1) It breaks projects that have resources. Fix is to attach the Executable
to only the 'copy to cmake build dir' phase. Even after the mailinglist
discussion I'm unsure of the need for this?
XCode basically claims it is a recursive dependency as the executable file
is added as a depenency on the Copy Files phase.
2) POST_BUILD targets stopped working. Re-added the code that uses those
(Before the copy-files target, maybe it should be after? I Really don't
understand the copy to cmake build dir phase.
Attached the original Patch from Nick modified to work with lastest git
master + two fixes mentioned above.
/Johan
On Sun, Feb 20, 2011 at 2:43 PM, Johan Björk p...@spotify.com wrote:
Hi Nick,
Any updates on this patch?
Cheers
/Johan
On Thu, Jan 20, 2011 at 2:08 AM, Nick Kledzik kled...@apple.com wrote:
BTW, it might make more sense to move this to the cmake-developers
mailing list.
I've transfered this thread to the developer list. See below for
continuation..
On Jan 18, 2011, at 12:42 PM, Bill Hoffman wrote:
On 1/18/2011 2:40 PM, Brad King wrote:
On 1/18/2011 2:12 PM, Nick Kledzik wrote:
When I use cmake to create a Makefile, the resulting main executable
is placed in the build directory tree next to the Makefile.
This is where CMake puts files in single-configuration generators.
When I use cmake to create a xcode project, the resulting main
executable is placed in a subdirectory named Debug of the build
directory tree.
This is where CMake puts files in multi-configuration generators.
Both of the above are expected default behaviors. Both can be
changed by CMake properties like RUNTIME_OUTPUT_DIRECTORY and
its per-configuration equivalent. All CMake generators must
honor these.
None of these locations are the native location
where Xcode would put a build result.
Xcode has settings like CONFIGURATION_BUILD_DIR to control
where the build outputs go. This already works. Is there
some reason your changes cannot use these?
My understanding is that the main problem with the current generator
is all the extra build phases and OTHER_LDFLAGS stuff used to deal
with link line ordering and static libraries. This is what Bill
summarized:
On 1/13/2011 3:41 PM, Bill Hoffman wrote:
- have a static library show up more than once on a link line
- be able to specify the order of static libraries on the link line
- be able to relink and executable when a static library that it
depends on is rebuilt.
I'm more interested in a solution to implementation issues like these
than in interface details like where output files go.
-Brad
So, for Xcode and VS IDE, CMake will place things in directories like
Debug, Release.
For example, you should get something like this:
${RUNTIME_OUTPUT_DIRECTORY}/Debug/myexe
Xcode does support building multiple configurations like Debug,
Release, etc. Where is the native location for those files?
As I said, it is per-user xcode settings. You cannot infer the location
from source tree cmake has access to.
At build time, the location is known within xcode. So, I added a
copy-file phase to have xocde copy the resulting binary from the native
location to the standard location the cmake expects. There is little
overhead for this.
I've now have a patch which:
1) preserves link order
2) builds libraries into the xcode native location
4) removes pre and post shell script phases previously used to fix
dependency problems
3) xcode projects now have proper dependencies
WIth this cmake patch, I can build CMake.xcodeproject, open it in xcode,
build-all, set the current target to be cmake, make a source change, hit
build, and have xcode just compile that one file, re-archive the library,
then re-link cmake tool. I also debugged all this in Xcode by setting
arguments for the cmake tool and hitting the build-and-debug within xcode!
Attached is the patch from cmake-2.8.3 sources:
This cmake also creates an xcode project that builds LLVM. It is still
not quite optimal because there are a bunch of cases where custom rules
cause a custom make file to be generated which is executed from within xcode
via a shell script phase. Xcode does not now which files the script might
modify, so xcode has to be conservative and re-check all timestamps. There
are ways to add custom scripts with specified input and output files in
xcode. I may get to fixing that someday...
How does one run the test suite? I saw the instructions about building
cmake for make, then executing make Experimental. I did that and all 184
or 184 tests passed. But it
Re: [cmake-developers] VS2010 fortran composer
On Mon, Mar 7, 2011 at 6:58 AM, Biddiscombe, John A. biddi...@cscs.ch wrote:
I've made some progress on a Fortran Composer generator for VS2010
If I create a fortran project, I can load it in the IDE and everything works
OK, but in order to do this I must detect the fortran compiler first. I am
doing this by running cmake using nmake makefiles, then changing the
generator in the cmakecach file manually to use the visual studio generator.
All is well.
Now that the generator is producing projects that load and compile (very
simple ones). I wanted to make the cmTryCompileExec run using the project
generator from first iteration.
When I try it, I get the following.
C:\cmakebuild\fortrantest\CMakeFiles\CMakeTmp\cmTryCompileExec.vfproj(2,1):
error MSB4075: The project file
C:\cmakebuild\fortrantest\CMakeFiles\CMakeTmp\cmTryCompileExec.vfproj must
be opened in the Visual Studio IDE and converted to the latest version before
it can be built by MSBuild.
At this point, I'm not sure what to do.
Has anyone encountered this message before? (google is not helping much for
me yet). I wonder if there is some completely different format used by
msbuild rather than the devenv. The fortran projects look completely
different to the cxx ones. simple vfproj attached for your reference.
PS. the ProjectIdGuid={1693218C-E07A-4FC1-9D1C-7100019B3A95} is just
copied from a generated project. How should I set this?
John,
Can you create a VS 2010 fortran project with the IDE, and then run
msbuild on it by hand (not from CMake)? If so, do that and then see
what the difference is between that one and the one you are
generating.
JB
?xml version=1.0 encoding=UTF-8?
VisualStudioProject ProjectCreator=Intel Fortran Keyword=Console
Application Version=11.0
ProjectIdGuid={1693218C-E07A-4FC1-9D1C-7100019B3A95}
Platforms
Platform Name=x64/
/Platforms
Configurations
Configuration Name=Debug|x64
Tool Name=VFFortranCompilerTool SuppressStartupBanner=true
DebugInformationFormat=debugEnabled Optimization=optimizeDisabled
Interfaces=true WarnInterfaces=true Traceback=true BoundsCheck=true
RuntimeLibrary=rtMultiThreadedDebug/
Tool Name=VFLinkerTool LinkIncremental=linkIncrementalNo
SuppressStartupBanner=true GenerateDebugInformation=true
SubSystem=subSystemConsole/
Tool Name=VFResourceCompilerTool/
Tool Name=VFMidlTool SuppressStartupBanner=true
TargetEnvironment=midlTargetAMD64/
Tool Name=VFCustomBuildTool/
Tool Name=VFPreLinkEventTool/
Tool Name=VFPreBuildEventTool/
Tool Name=VFPostBuildEventTool/
Tool Name=VFManifestTool SuppressStartupBanner=true//Configuration
Configuration Name=Release|x64
Tool Name=VFFortranCompilerTool SuppressStartupBanner=true/
Tool Name=VFLinkerTool LinkIncremental=linkIncrementalNo
SuppressStartupBanner=true SubSystem=subSystemConsole/
Tool Name=VFResourceCompilerTool/
Tool Name=VFMidlTool SuppressStartupBanner=true
TargetEnvironment=midlTargetAMD64/
Tool Name=VFCustomBuildTool/
Tool Name=VFPreLinkEventTool/
Tool Name=VFPreBuildEventTool/
Tool Name=VFPostBuildEventTool/
Tool Name=VFManifestTool SuppressStartupBanner=true//Configuration
/Configurations
Files
Filter Name=Header Files Filter=fi;fd/
Filter Name=Resource Files
Filter=rc;ico;cur;bmp;dlg;rc2;rct;bin;rgs;gif;jpg;jpeg;jpe/
Filter Name=Source Files Filter=f90;for;f;fpp;ftn;def;odl;idl
File RelativePath=testFortranCompiler.f//Filter/Files
Globals//VisualStudioProject
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] VS2010 fortran composer
No. The cmake generated project is identical to the one I create using visual studio - and both compile fine inside the IDE but both give the same error when I try to compile using MSBuild here is the outpur from a simple TestApp generated using the IDE (New Project etc etc) C:\Code\fortrantest\TestApp\TestAppC:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe TestApp.vfproj Microsoft (R) Build Engine Version 4.0.30319.1 [Microsoft .NET Framework, Version 4.0.30319.1] Copyright (C) Microsoft Corporation 2007. All rights reserved. Build started 07/03/2011 14:41:43. Project C:\Code\fortrantest\TestApp\TestApp\TestApp.vfproj on node 1 (default targets). C:\Code\fortrantest\TestApp\TestApp\TestApp.vfproj(2,1): error MSB4075: The project file C:\Code\fortrantest\TestApp\TestApp\TestApp.vfpro j must be opened in the Visual Studio IDE and converted to the latest version before it can be built by MSBuild. Done Building Project C:\Code\fortrantest\TestApp\TestApp\TestApp.vfproj (default targets) -- FAILED. Build FAILED. C:\Code\fortrantest\TestApp\TestApp\TestApp.vfproj (default target) (1) - C:\Code\fortrantest\TestApp\TestApp\TestApp.vfproj(2,1): error MSB4075: The project file C:\Code\fortrantest\TestApp\TestApp\TestApp.vfproj must be opened in the Visual Studio IDE and converted to the latest version before it can be built by MSBuild. 0 Warning(s) 1 Error(s) Time Elapsed 00:00:00.04 ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] VS2010 fortran composer
http://software.intel.com/en-us/forums/showthread.php?t=81140 This is explained in the release notes for the Fortran compiler. Please read the section on VS2010.. John, do you have the release notes? On Mon, Mar 7, 2011 at 8:57 AM, Bill Hoffman bill.hoff...@kitware.com wrote: On Mon, Mar 7, 2011 at 8:43 AM, Biddiscombe, John A. biddi...@cscs.ch wrote: No. The cmake generated project is identical to the one I create using visual studio - and both compile fine inside the IDE but both give the same error when I try to compile using MSBuild here is the outpur from a simple TestApp generated using the IDE (New Project etc etc) Sounds like a bug report for Intel. If you create a project with the IDE, and it fails to build with MSBuild, then I don't really see how you are going to figure it out You could try something like this: http://stackoverflow.com/questions/956163/msbuild-error-when-building-projects-for-the-first-time What if you run DevEnv.exe from the command line with the /Upgrade on the vfproj file? Does it change it? Does it work with MSBuild after? C:\Code\fortrantest\TestApp\TestAppC:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe TestApp.vfproj Microsoft (R) Build Engine Version 4.0.30319.1 [Microsoft .NET Framework, Version 4.0.30319.1] Copyright (C) Microsoft Corporation 2007. All rights reserved. Build started 07/03/2011 14:41:43. Project C:\Code\fortrantest\TestApp\TestApp\TestApp.vfproj on node 1 (default targets). C:\Code\fortrantest\TestApp\TestApp\TestApp.vfproj(2,1): error MSB4075: The project file C:\Code\fortrantest\TestApp\TestApp\TestApp.vfpro j must be opened in the Visual Studio IDE and converted to the latest version before it can be built by MSBuild. Done Building Project C:\Code\fortrantest\TestApp\TestApp\TestApp.vfproj (default targets) -- FAILED. Build FAILED. C:\Code\fortrantest\TestApp\TestApp\TestApp.vfproj (default target) (1) - C:\Code\fortrantest\TestApp\TestApp\TestApp.vfproj(2,1): error MSB4075: The project file C:\Code\fortrantest\TestApp\TestApp\TestApp.vfproj must be opened in the Visual Studio IDE and converted to the latest version before it can be built by MSBuild. 0 Warning(s) 1 Error(s) Time Elapsed 00:00:00.04 ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] VS2010 fortran composer
Bill What if you run DevEnv.exe from the command line with the /Upgrade on the vfproj file? Does it change it? Does it work with MSBuild after? No change. Still fails. http://software.intel.com/en-us/forums/showthread.php?t=81140 This is explained in the release notes for the Fortran compiler. Please read the section on VS2010.. yes I found this report - unfortunately it does not tell us anything useful. It deals with dependencies, which is different from our problem. I checked to see the the ALL_BUILD project was referencing the cmTryComile, (and it is), but changing this makes no difference - when running msbuild.exe we only treat the cmtrycompile and deleting all the other stuff doesn't solve anything. I'll file a bug report with intel and for now, use makefiles to kick off the generator and then switch.- could we not just use nmake always for the compiler detection step? JB snippet from release notes below 3.6.2 Adjusting Project Dependencies If you are converting a project from an earlier version of Visual Studio and had established Project Dependencies, these are converted to References by Visual Studio 2010. A Fortran project that is referenced by a C/C++ project will prevent the C/C++ project from building, with an MSB4075 error. To solve this: 1. Right click on the C/C++ project and select References. 2. If any Fortran project is shown as a reference, click Remove Reference. Repeat this for all Fortran projects shown as a reference. Click OK. 3. Repeat the above steps for any other C/C++ project Now you have to reestablish project dependencies. 1. Right click on the C/C++ project and select Project Dependencies. 2. Check the box for each project that is a dependent of this project. 3. Click OK. 4. Repeat the above steps for any other C/C++ project that has dependencies. Unlike earlier versions of Visual Studio, Visual Studio 2010 does not automatically link in the output library of dependent projects, so you will need to add those libraries explicitly to the parent project under Linker Additional Dependencies. You can use the Visual Studio macros $(ConfigurationName) and $(PlatformName) as required to qualify the path. For example: ..\FLIB\$(ConfigurationName)\FLIB.lib Where $(ConfigurationName) will expand to Release or Debug, as appropriate. Similarly, $(PlatformName) will expand to Win32 or x64 as appropriate. ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] VS2010 fortran composer
On Mon, Mar 7, 2011 at 9:17 AM, Biddiscombe, John A. biddi...@cscs.ch wrote: Bill What if you run DevEnv.exe from the command line with the /Upgrade on the vfproj file? Does it change it? Does it work with MSBuild after? No change. Still fails. http://software.intel.com/en-us/forums/showthread.php?t=81140 This is explained in the release notes for the Fortran compiler. Please read the section on VS2010.. yes I found this report - unfortunately it does not tell us anything useful. It deals with dependencies, which is different from our problem. I checked to see the the ALL_BUILD project was referencing the cmTryComile, (and it is), but changing this makes no difference - when running msbuild.exe we only treat the cmtrycompile and deleting all the other stuff doesn't solve anything. I'll file a bug report with intel and for now, use makefiles to kick off the generator and then switch.- could we not just use nmake always for the compiler detection step? When you file the report, do not include any mention of CMake. I would just tell them that you did this: 1. create a new hello world application with the IDE 2. run msbuild on the application 3. you get an error We can not use nmake to kick off the generator, it would not even be testing the same setup that the generator is creating. Might as well disable all try-compiles because it would not even be testing what the user would be seeing during the real build We might be able to use devenv /build, however in earlier versions of VS 2010 using devenv for running the tests of CMake caused devenv to crash multiple times... -Bill JB snippet from release notes below 3.6.2 Adjusting Project Dependencies If you are converting a project from an earlier version of Visual Studio and had established Project Dependencies, these are converted to References by Visual Studio 2010. A Fortran project that is referenced by a C/C++ project will prevent the C/C++ project from building, with an MSB4075 error. To solve this: 1. Right click on the C/C++ project and select References. 2. If any Fortran project is shown as a reference, click Remove Reference. Repeat this for all Fortran projects shown as a reference. Click OK. 3. Repeat the above steps for any other C/C++ project Now you have to reestablish project dependencies. 1. Right click on the C/C++ project and select Project Dependencies. 2. Check the box for each project that is a dependent of this project. 3. Click OK. 4. Repeat the above steps for any other C/C++ project that has dependencies. Unlike earlier versions of Visual Studio, Visual Studio 2010 does not automatically link in the output library of dependent projects, so you will need to add those libraries explicitly to the parent project under Linker Additional Dependencies. You can use the Visual Studio macros $(ConfigurationName) and $(PlatformName) as required to qualify the path. For example: ..\FLIB\$(ConfigurationName)\FLIB.lib Where $(ConfigurationName) will expand to Release or Debug, as appropriate. Similarly, $(PlatformName) will expand to Win32 or x64 as appropriate. ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] VS2010 fortran composer
I tried the /Upgrade with devenv.exe and it did nothing. After reading more intel forum posts I discover that the fortran projects cannot be built using msbuild. Intentional at some levele. But I realized that I should be using devenv.com not devenv.exe C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.com TestApp.vfproj /Upgrade Microsoft (R) Visual Studio Version 10.0.30319.1. Copyright (C) Microsoft Corp. All rights reserved. Information: This project/solution does not require conversion. but I can build the projects using devenv.com instead of msbuild. Can I change the GenerateBuildCommand which create the cmTryCompileExec to use devenv.com? C:\cmakebuild\fortrantest\CMakeFiles\CMakeTmpdevenv.com cmTryCompileExec.vfproj /Build Debug|x64 Microsoft (R) Visual Studio Version 10.0.30319.1. Copyright (C) Microsoft Corp. All rights reserved. 1-- Build started: Project: cmTryCompileExec, Configuration: Debug x64 -- 1Compiling with Intel(R) Visual Fortran Compiler XE 12.0.0.104 [Intel(R) 64]... 1testFortranCompiler.f 1Linking... 1Embedding manifest... 1 1Build log written to file://C:\cmakebuild\fortrantest\CMakeFiles\CMakeTmp\x64\Debug\BuildLog.htm 1cmTryCompileExec - 0 error(s), 0 warning(s) == Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped == JB -Original Message- From: Bill Hoffman [mailto:bill.hoff...@kitware.com] Sent: 07 March 2011 15:42 To: Biddiscombe, John A. Cc: cmake-developers@cmake.org Subject: Re: VS2010 fortran composer On Mon, Mar 7, 2011 at 9:17 AM, Biddiscombe, John A. biddi...@cscs.ch wrote: Bill What if you run DevEnv.exe from the command line with the /Upgrade on the vfproj file? Does it change it? Does it work with MSBuild after? No change. Still fails. http://software.intel.com/en-us/forums/showthread.php?t=81140 This is explained in the release notes for the Fortran compiler. Please read the section on VS2010.. yes I found this report - unfortunately it does not tell us anything useful. It deals with dependencies, which is different from our problem. I checked to see the the ALL_BUILD project was referencing the cmTryComile, (and it is), but changing this makes no difference - when running msbuild.exe we only treat the cmtrycompile and deleting all the other stuff doesn't solve anything. I'll file a bug report with intel and for now, use makefiles to kick off the generator and then switch.- could we not just use nmake always for the compiler detection step? When you file the report, do not include any mention of CMake. I would just tell them that you did this: 1. create a new hello world application with the IDE 2. run msbuild on the application 3. you get an error We can not use nmake to kick off the generator, it would not even be testing the same setup that the generator is creating. Might as well disable all try-compiles because it would not even be testing what the user would be seeing during the real build We might be able to use devenv /build, however in earlier versions of VS 2010 using devenv for running the tests of CMake caused devenv to crash multiple times... -Bill JB snippet from release notes below 3.6.2 Adjusting Project Dependencies If you are converting a project from an earlier version of Visual Studio and had established Project Dependencies, these are converted to References by Visual Studio 2010. A Fortran project that is referenced by a C/C++ project will prevent the C/C++ project from building, with an MSB4075 error. To solve this: 1. Right click on the C/C++ project and select References. 2. If any Fortran project is shown as a reference, click Remove Reference. Repeat this for all Fortran projects shown as a reference. Click OK. 3. Repeat the above steps for any other C/C++ project Now you have to reestablish project dependencies. 1. Right click on the C/C++ project and select Project Dependencies. 2. Check the box for each project that is a dependent of this project. 3. Click OK. 4. Repeat the above steps for any other C/C++ project that has dependencies. Unlike earlier versions of Visual Studio, Visual Studio 2010 does not automatically link in the output library of dependent projects, so you will need to add those libraries explicitly to the parent project under Linker Additional Dependencies. You can use the Visual Studio macros $(ConfigurationName) and $(PlatformName) as required to qualify the path. For example: ..\FLIB\$(ConfigurationName)\FLIB.lib Where $(ConfigurationName) will expand to Release or Debug, as appropriate. Similarly, $(PlatformName) will expand to Win32 or x64 as appropriate. ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] VS2010 fortran composer
I just tried this on a remote machine with the compiler and can confirm what John is seeing. That said. If you run msbuild on the top level solution you get a slightly more informative error. c:\Users\kitware\Documents\Visual Studio 2010\Projects\Console1msbuild Console1.sln Microsoft (R) Build Engine Version 3.5.30729.1 [Microsoft .NET Framework, Version 2.0.50727.4206] Copyright (C) Microsoft Corporation 2007. All rights reserved. Build started 3/7/2011 10:10:25 AM. Project c:\Users\kitware\Documents\Visual Studio 2010\Projects\Console1\Console1.sln on node 0 (default targets). Building solution configuration Debug|Win32. c:\Users\kitware\Documents\Visual Studio 2010\Projects\Console1\Console1.sln.cache : warning MSB4078: The project file Console1\Console1.vfproj is not supported by MSBuild and cannot be built. Done Building Project c:\Users\kitware\Documents\Visual Studio 2010\Projects\Console1\Console1.sln (default targets). Build succeeded. c:\Users\kitware\Documents\Visual Studio 2010\Projects\Console1\Console1.sln (default target) (1) - (Console1 target) - c:\Users\kitware\Documents\Visual Studio 2010\Projects\Console1\Console1.sln.cache : warning MSB4078: The project file Console1\Console1.vfproj is not supporte d by MSBuild and cannot be built. 1 Warning(s) 0 Error(s) Time Elapsed 00:00:00.01 On Mon, Mar 7, 2011 at 9:42 AM, Bill Hoffman bill.hoff...@kitware.comwrote: On Mon, Mar 7, 2011 at 9:17 AM, Biddiscombe, John A. biddi...@cscs.ch wrote: Bill What if you run DevEnv.exe from the command line with the /Upgrade on the vfproj file? Does it change it? Does it work with MSBuild after? No change. Still fails. http://software.intel.com/en-us/forums/showthread.php?t=81140 This is explained in the release notes for the Fortran compiler. Please read the section on VS2010.. yes I found this report - unfortunately it does not tell us anything useful. It deals with dependencies, which is different from our problem. I checked to see the the ALL_BUILD project was referencing the cmTryComile, (and it is), but changing this makes no difference - when running msbuild.exe we only treat the cmtrycompile and deleting all the other stuff doesn't solve anything. I'll file a bug report with intel and for now, use makefiles to kick off the generator and then switch.- could we not just use nmake always for the compiler detection step? When you file the report, do not include any mention of CMake. I would just tell them that you did this: 1. create a new hello world application with the IDE 2. run msbuild on the application 3. you get an error We can not use nmake to kick off the generator, it would not even be testing the same setup that the generator is creating. Might as well disable all try-compiles because it would not even be testing what the user would be seeing during the real build We might be able to use devenv /build, however in earlier versions of VS 2010 using devenv for running the tests of CMake caused devenv to crash multiple times... -Bill JB snippet from release notes below 3.6.2 Adjusting Project Dependencies If you are converting a project from an earlier version of Visual Studio and had established Project Dependencies, these are converted to References by Visual Studio 2010. A Fortran project that is referenced by a C/C++ project will prevent the C/C++ project from building, with an MSB4075 error. To solve this: 1. Right click on the C/C++ project and select References. 2. If any Fortran project is shown as a reference, click Remove Reference. Repeat this for all Fortran projects shown as a reference. Click OK. 3. Repeat the above steps for any other C/C++ project Now you have to reestablish project dependencies. 1. Right click on the C/C++ project and select Project Dependencies. 2. Check the box for each project that is a dependent of this project. 3. Click OK. 4. Repeat the above steps for any other C/C++ project that has dependencies. Unlike earlier versions of Visual Studio, Visual Studio 2010 does not automatically link in the output library of dependent projects, so you will need to add those libraries explicitly to the parent project under Linker Additional Dependencies. You can use the Visual Studio macros $(ConfigurationName) and $(PlatformName) as required to qualify the path. For example: ..\FLIB\$(ConfigurationName)\FLIB.lib Where $(ConfigurationName) will expand to Release or Debug, as appropriate. Similarly, $(PlatformName) will expand to Win32 or x64 as appropriate. ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] VS2010 fortran composer
On Mon, Mar 7, 2011 at 10:13 AM, Biddiscombe, John A. biddi...@cscs.ch wrote: I tried the /Upgrade with devenv.exe and it did nothing. After reading more intel forum posts I discover that the fortran projects cannot be built using msbuild. Intentional at some levele. But I realized that I should be using devenv.com not devenv.exe C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.com TestApp.vfproj /Upgrade Microsoft (R) Visual Studio Version 10.0.30319.1. Copyright (C) Microsoft Corp. All rights reserved. Information: This project/solution does not require conversion. but I can build the projects using devenv.com instead of msbuild. Can I change the GenerateBuildCommand which create the cmTryCompileExec to use devenv.com? C:\cmakebuild\fortrantest\CMakeFiles\CMakeTmpdevenv.com cmTryCompileExec.vfproj /Build Debug|x64 This can be done... Try to change Modules/CMakeVS10FindMake.cmake, make it look like CMakeVS9FindMake.cmake. Like I said before last time I tried this devenv crashed a bunch of times during the CMake tests. You will have to run on a new build tree for this to work once you make the change. If it does work, we can hope they have fixed devenv /build... Or, maybe only use it for fortran, but that would be hard... -Bill ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] VS2010 fortran composer
Or, maybe only use it for fortran, but that would be hard... Ah. That was going to be my next question. I wanted to know how to get the cmTarget object inside the GenerateBuildCommand function, because I need to tell it to use vfproj instead of vcxproj (since I'm using different extensions). If I know it's a fortran test, then I should be able to change the command line and the extension JB ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] VS2010 fortran composer
On Mon, Mar 7, 2011 at 10:29 AM, Biddiscombe, John A. biddi...@cscs.ch wrote: Or, maybe only use it for fortran, but that would be hard... Ah. That was going to be my next question. I wanted to know how to get the cmTarget object inside the GenerateBuildCommand function, because I need to tell it to use vfproj instead of vcxproj (since I'm using different extensions). If I know it's a fortran test, then I should be able to change the command line and the extension Should be able to do that all in cmVisualStudio10TargetGenerator::Generate. It is only one target at that time, and you should be able to check to make sure it is a fortran target. But, this is not the same place that the build command is created... However, that said we might be able to do something that looks at the file extension and does the switch. However, maybe it will all just work with devenv.com as the build tool. JB ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] VS2010 fortran composer
On Mon, Mar 7, 2011 at 10:35 AM, Bill Hoffman bill.hoff...@kitware.comwrote: On Mon, Mar 7, 2011 at 10:29 AM, Biddiscombe, John A. biddi...@cscs.ch wrote: Or, maybe only use it for fortran, but that would be hard... Ah. That was going to be my next question. I wanted to know how to get the cmTarget object inside the GenerateBuildCommand function, because I need to tell it to use vfproj instead of vcxproj (since I'm using different extensions). If I know it's a fortran test, then I should be able to change the command line and the extension Should be able to do that all in cmVisualStudio10TargetGenerator::Generate. It is only one target at that time, and you should be able to check to make sure it is a fortran target. But, this is not the same place that the build command is created... However, that said we might be able to do something that looks at the file extension and does the switch. However, maybe it will all just work with devenv.com as the build tool. JB ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers After this change was pushed: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=2ca116189f26e758a47d4737afe21853d0676235 (which is in CMake 2.8.4)... it should be possible to simply set CMAKE_MAKE_PROGRAM to the full path to devenv and use that to build rather than MSBuild. -DCMAKE_MAKE_PROGRAM:FILEPATH=C:/full/path/to/devenv.com HTH, David ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0011937]: Need determination of Intel C++ compiler version
The following issue has been SUBMITTED.
==
http://public.kitware.com/Bug/view.php?id=11937
==
Reported By:Daniel R. Gomez
Assigned To:
==
Project:CMake
Issue ID: 11937
Category: CMake
Reproducibility:always
Severity: feature
Priority: normal
Status: new
==
Date Submitted: 2011-03-07 14:22 EST
Last Modified: 2011-03-07 14:22 EST
==
Summary:Need determination of Intel C++ compiler version
Description:
When the MSVC compiler is used, CMake will determine the version for you and set
MSVC_VERSION accordingly, as well as set MSVC60, MSVC71, MSVC80 et al.
When you use the Intel C++ compiler, however, you don't get any information on
the compiler version. This can be a problem if you want to support multiple
versions of the compiler, using mutually-incompatible compiler flags.
I've put together a code fragment, modeled on the MSVC version-finding part of
Modules/Platform/Windows-cl.cmake, that does this for ICC. It is attached.
Some notes:
* In modifying the MSVC version-finding code, I generally translated MSVC-ICC
and CL-ICL. The terms ICC versus ICL are related in much the same way as
MSVC versus CL.
* This fragment can be added to Modules/Platform/Windows-icl.cmake (in the
source repository) or Modules/Platform/Windows-Intel.cmake (in 2.8.4).
* The code refers to a C file CMakeTestNMakeICLVersion.c, which contains the
following:
VERSION=__INTEL_COMPILER
However, with some tweaking, you could have Windows-cl.cmake and this code make
use of the same file, by combining them into e.g.
VERSION_CL=_MSC_VER
VERSION_ICL=__INTEL_COMPILER
and adjusting the regexes appropriately.
* This code only covers the case of the Intel compiler used with a makefile
generator. ICC can be used within Visual Studio, and the various ICC${version}
and ICC_VERSION variables ought to be available in that case, too. I only use
ICC with the NMake Makefiles generator, however, so making that work is a bit
out of my purview.
==
Issue History
Date ModifiedUsername FieldChange
==
2011-03-07 14:22 Daniel R. GomezNew Issue
2011-03-07 14:22 Daniel R. GomezFile Added: icc-get-version.cmake
==
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] How to deal with assembler files
On Friday 04 March 2011, Brad King wrote: On 03/03/2011 05:04 PM, Alexander Neundorf wrote: On Thursday 03 March 2011, Brad King wrote: Hi Alex, The Sun compiler still fails: http://www.cdash.org/CDash/testDetails.php?test=85204365build=888421 It's because the execute_process in the CMakeLists.txt file of the test does not use the C compiler flags. Therefore 32-bit assembly code is generated and then it tries to compile it with 64-bit flags. Ok, merged into next, I hope it works. I disabled the assembler test for Intel under Windows for now. I just added a few more fixes/changes to the topic. The CMAKE_C_FLAGS have to be parsed because they are space-separated. We also now use a custom command to generate main.s and enable verbose make output. Now the test should print out all the command lines in its output. Dashboard is green now, thanks :-) What is left to do ? Testing the Intel compiler under Windows... More ? Alex ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] [CMake 0011938]: CMake ADD_CUSTOM_COMMAND with working directory problem in Visual Studio 2010
The following issue has been SUBMITTED.
==
http://cmake.org/Bug/view.php?id=11938
==
Reported By:strcasecmp
Assigned To:
==
Project:CMake
Issue ID: 11938
Category: CMake
Reproducibility:always
Severity: minor
Priority: normal
Status: new
==
Date Submitted: 2011-03-08 01:30 EST
Last Modified: 2011-03-08 01:30 EST
==
Summary:CMake ADD_CUSTOM_COMMAND with working directory
problem in Visual Studio 2010
Description:
Apparently (based on my searches) in Visual Studio 2010, all custom build
targets for a given project get executed within the same batch file generated by
VS. As a result, if a cmake custom command has a working directory set, the
resultant cd in the build rule can interfere with subsequent custom build
rules.
This becomes a problem that can't be easily worked-around when building Qt
projects (the Qt macros create their own custom commands).
In the Qt example, I was able to confirm that the cd was the cause by adding a
cd back to the ${CMAKE_CURRENT_BINARY_DIR} at the start of the failing custom
command, or by modifying the QT4_CREATE_MOC_COMMAND macro to avoid using the
WORKING_DIRECTORY.
Steps to Reproduce:
For simplest reproduction (though, not the only way), the attached sample may be
used. To cause this sample to trigger the problem, cmake must be run from a
location within this project directory. This causes a relative path to be used
for the cmake command used in the CMakeLists.txt custom build tool.
The layout is as follows:
simple/
simple/hello.in
simple/CMakeLists.txt
simple/build/
Extract/copy cmake into the simple/ directory and run from the build
subdirectory:
..\cmakedir\bin\cmake-gui.exe ..
Generate a VS2010 project/solution.
Then attempt to build the resultant solution.
Additional Information:
This could probably be easily (and probably correctly) solved by having the
VS2010 generator do a cd back to the current binary directory at the end of each
custom command (or a pushd/popd pair).
==
Issue History
Date ModifiedUsername FieldChange
==
2011-03-08 01:30 strcasecmp New Issue
2011-03-08 01:30 strcasecmp File Added: simple.zip
==
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [CMake] Multiple library configurations with the same output name
Usually there are 2 ways: 1) put them into separate directories (like Debug and Release), probably specifying different output directories or 2) use different file names, say adding suffixes like D, or d8. BTW, what's the point to have different configurations in the same workspace (do you really still use VC6?) in different projects? Usually for Visual Studio configuration is coded into output directory path using macros like $(Configuration), so resulting binaries are put into different dirs. And you have to build twise to get all configurations. Why do they required to have the same name? May be you're trying to solve wrong problem? I don't need a new configuration like debug or release, but multiple versions of our software. Same names for targets is a must. CMake build process already works fine, I just try to optimize it. Yes, I have to use VC6, because of legacy code. -- BG, Alexey ___ 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] CMake command line arguments
On 03/06/2011 12:12 PM, Gabriel Petrovay wrote:
Hi,
Is there a way to read the arguments that were passed to CMake from
inside a CMakeLists.txt file?
There is a problem that some generators (like NMake Makefiles) set a
default value for certain variables (like CMAKE_BUILD_TYPE=Debug,
CMAKE_INSTALL_PREFIX=C:\Program Files\${CMAKE_PROJECT_NAME})
From inside CMake one can not set up a different default value if the
user does not specify it with a -D option. This is because
IF(CMAKE_BUILD_TYPE) will always be true because of the default set by
the generator (NMake Makefiles).
There was this guy having the same problem:
http://www.mail-archive.com/cmake@cmake.org/msg09640.html
Any solution how one can solve this? Reading the arguments passed to
CMake would be one, but I find no documentation/example/google_result
for this.
Thanks!
Scanning the command line for user-supplied settings wouldn't be
reliable because your project might also be configured via a GUI.
Furthermore, even an empty CMAKE_BUILD_TYPE variable may denote a
valid build type, so there's no robust criterion to decide when to
set a default value by examining this variable alone. Instead, you
might use another variable, say ${PROJECT_NAME}_BUILD_TYPE, and do:
IF(NOT DEFINED ${PROJECT_NAME}_BUILD_TYPE)
SET(${PROJECT_NAME}_BUILD_TYPE CUSTOM)
ENDIF()
SET(CMAKE_BUILD_TYPE ${${PROJECT_NAME}_BUILD_TYPE})
In this way, an undefined ${PROJECT_NAME}_BUILD_TYPE results in a
default CMAKE_BUILD_TYPE on behalf of the CMakeLists.txt file. Of
course, you should document that variable and urge your project's
users to not directly use CMAKE_BUILD_TYPE anymore; perhaps, you
should even hide the latter in a GUI by marking it as advanced.
With regard to CMAKE_INSTALL_PREFIX, you could do the same - or use
CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT, as a robust criterion,
to see whether the user has supplied a value explicitly. Note that
there're additional aspects to consider if the CMakeLists.txt file
is to write that variable's value to the cache, cf. [1] et seq.
Regards,
Michael
[1] http://www.mail-archive.com/cmake@cmake.org/msg32848.html
___
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] Documentation for CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT missing?
Hi, I just wanted to read the documentation on CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT, but discovered that the variable is not listed in the cmake docs. Is there a reason for this? Should I open a bugreport on it? Cheers, Johannes -- Johannes Zarl Virtual Reality Services Johannes Kepler University Informationsmanagement Altenbergerstrasze 69 4040 Linz, Austria Phone: +43 732 2468-8321 johannes.z...@jku.at http://vrc.zid.jku.at ___ 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] CMake command line arguments
On 03/07/2011 11:33 AM, Michael Hertling wrote:
On 03/06/2011 12:12 PM, Gabriel Petrovay wrote:
Hi,
Is there a way to read the arguments that were passed to CMake from
inside a CMakeLists.txt file?
There is a problem that some generators (like NMake Makefiles) set a
default value for certain variables (like CMAKE_BUILD_TYPE=Debug,
CMAKE_INSTALL_PREFIX=C:\Program Files\${CMAKE_PROJECT_NAME})
From inside CMake one can not set up a different default value if the
user does not specify it with a -D option. This is because
IF(CMAKE_BUILD_TYPE) will always be true because of the default set by
the generator (NMake Makefiles).
There was this guy having the same problem:
http://www.mail-archive.com/cmake@cmake.org/msg09640.html
Any solution how one can solve this? Reading the arguments passed to
CMake would be one, but I find no documentation/example/google_result
for this.
Thanks!
Scanning the command line for user-supplied settings wouldn't be
reliable because your project might also be configured via a GUI.
Furthermore, even an empty CMAKE_BUILD_TYPE variable may denote a
valid build type, so there's no robust criterion to decide when to
set a default value by examining this variable alone. Instead, you
might use another variable, say ${PROJECT_NAME}_BUILD_TYPE, and do:
IF(NOT DEFINED ${PROJECT_NAME}_BUILD_TYPE)
SET(${PROJECT_NAME}_BUILD_TYPE CUSTOM)
ENDIF()
SET(CMAKE_BUILD_TYPE ${${PROJECT_NAME}_BUILD_TYPE})
Alternatively, you might do:
SET(${PROJECT_NAME}_BUILD_TYPE CUSTOM
CACHE STRING ${PROJECT_NAME} Build Type)
SET(CMAKE_BUILD_TYPE ${${PROJECT_NAME}_BUILD_TYPE})
So, you'll have at least your project's own build type in the cache -
and, thus, in the GUIs - along with the documenting comment while the
cached value of CMAKE_BUILD_TYPE is still not the one that's actually
used.
In this way, an undefined ${PROJECT_NAME}_BUILD_TYPE results in a
default CMAKE_BUILD_TYPE on behalf of the CMakeLists.txt file. Of
course, you should document that variable and urge your project's
users to not directly use CMAKE_BUILD_TYPE anymore; perhaps, you
should even hide the latter in a GUI by marking it as advanced.
With regard to CMAKE_INSTALL_PREFIX, you could do the same - or use
CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT, as a robust criterion,
to see whether the user has supplied a value explicitly. Note that
there're additional aspects to consider if the CMakeLists.txt file
is to write that variable's value to the cache, cf. [1] et seq.
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] CMake command line arguments
Thanks for the tips, Michael.
We will do so, using project specific BUILD_TYPE and INSTALL_PREFIX.
Gabriel
On Mon, Mar 7, 2011 at 12:20 PM, Michael Hertling mhertl...@online.de wrote:
On 03/07/2011 11:33 AM, Michael Hertling wrote:
On 03/06/2011 12:12 PM, Gabriel Petrovay wrote:
Hi,
Is there a way to read the arguments that were passed to CMake from
inside a CMakeLists.txt file?
There is a problem that some generators (like NMake Makefiles) set a
default value for certain variables (like CMAKE_BUILD_TYPE=Debug,
CMAKE_INSTALL_PREFIX=C:\Program Files\${CMAKE_PROJECT_NAME})
From inside CMake one can not set up a different default value if the
user does not specify it with a -D option. This is because
IF(CMAKE_BUILD_TYPE) will always be true because of the default set by
the generator (NMake Makefiles).
There was this guy having the same problem:
http://www.mail-archive.com/cmake@cmake.org/msg09640.html
Any solution how one can solve this? Reading the arguments passed to
CMake would be one, but I find no documentation/example/google_result
for this.
Thanks!
Scanning the command line for user-supplied settings wouldn't be
reliable because your project might also be configured via a GUI.
Furthermore, even an empty CMAKE_BUILD_TYPE variable may denote a
valid build type, so there's no robust criterion to decide when to
set a default value by examining this variable alone. Instead, you
might use another variable, say ${PROJECT_NAME}_BUILD_TYPE, and do:
IF(NOT DEFINED ${PROJECT_NAME}_BUILD_TYPE)
SET(${PROJECT_NAME}_BUILD_TYPE CUSTOM)
ENDIF()
SET(CMAKE_BUILD_TYPE ${${PROJECT_NAME}_BUILD_TYPE})
Alternatively, you might do:
SET(${PROJECT_NAME}_BUILD_TYPE CUSTOM
CACHE STRING ${PROJECT_NAME} Build Type)
SET(CMAKE_BUILD_TYPE ${${PROJECT_NAME}_BUILD_TYPE})
So, you'll have at least your project's own build type in the cache -
and, thus, in the GUIs - along with the documenting comment while the
cached value of CMAKE_BUILD_TYPE is still not the one that's actually
used.
In this way, an undefined ${PROJECT_NAME}_BUILD_TYPE results in a
default CMAKE_BUILD_TYPE on behalf of the CMakeLists.txt file. Of
course, you should document that variable and urge your project's
users to not directly use CMAKE_BUILD_TYPE anymore; perhaps, you
should even hide the latter in a GUI by marking it as advanced.
With regard to CMAKE_INSTALL_PREFIX, you could do the same - or use
CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT, as a robust criterion,
to see whether the user has supplied a value explicitly. Note that
there're additional aspects to consider if the CMakeLists.txt file
is to write that variable's value to the cache, cf. [1] et seq.
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
--
MSc Gabriel Petrovay
Mobile: +41(0)787978034
www.28msec.com
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CMake command line arguments
On 03/07/2011 12:37 PM, Gabriel Petrovay wrote:
Thanks for the tips, Michael.
We will do so, using project specific BUILD_TYPE and INSTALL_PREFIX.
However, the downside of this approach is that your project's users
should not refer to the well-known CMake variables CMAKE_BUILD_TYPE
and CMAKE_INSTALL_PREFIX anymore - possibly an issue to consider.
On Mon, Mar 7, 2011 at 12:20 PM, Michael Hertling mhertl...@online.de wrote:
On 03/07/2011 11:33 AM, Michael Hertling wrote:
On 03/06/2011 12:12 PM, Gabriel Petrovay wrote:
Hi,
Is there a way to read the arguments that were passed to CMake from
inside a CMakeLists.txt file?
There is a problem that some generators (like NMake Makefiles) set a
default value for certain variables (like CMAKE_BUILD_TYPE=Debug,
CMAKE_INSTALL_PREFIX=C:\Program Files\${CMAKE_PROJECT_NAME})
From inside CMake one can not set up a different default value if the
user does not specify it with a -D option. This is because
IF(CMAKE_BUILD_TYPE) will always be true because of the default set by
the generator (NMake Makefiles).
There was this guy having the same problem:
http://www.mail-archive.com/cmake@cmake.org/msg09640.html
Any solution how one can solve this? Reading the arguments passed to
CMake would be one, but I find no documentation/example/google_result
for this.
Thanks!
Scanning the command line for user-supplied settings wouldn't be
reliable because your project might also be configured via a GUI.
Furthermore, even an empty CMAKE_BUILD_TYPE variable may denote a
valid build type, so there's no robust criterion to decide when to
set a default value by examining this variable alone. Instead, you
might use another variable, say ${PROJECT_NAME}_BUILD_TYPE, and do:
IF(NOT DEFINED ${PROJECT_NAME}_BUILD_TYPE)
SET(${PROJECT_NAME}_BUILD_TYPE CUSTOM)
ENDIF()
SET(CMAKE_BUILD_TYPE ${${PROJECT_NAME}_BUILD_TYPE})
Alternatively, you might do:
SET(${PROJECT_NAME}_BUILD_TYPE CUSTOM
CACHE STRING ${PROJECT_NAME} Build Type)
SET(CMAKE_BUILD_TYPE ${${PROJECT_NAME}_BUILD_TYPE})
So, you'll have at least your project's own build type in the cache -
and, thus, in the GUIs - along with the documenting comment while the
cached value of CMAKE_BUILD_TYPE is still not the one that's actually
used.
If you say
SET(CMAKE_BUILD_TYPE ${${PROJECT_NAME}_BUILD_TYPE}
CACHE STRING CMake Build Type FORCE)
here, the cached value of CMAKE_BUILD_TYPE will equal the value in the
current scope again. Obviously, I'm quite unconcentrated today... ;-)
In this way, an undefined ${PROJECT_NAME}_BUILD_TYPE results in a
default CMAKE_BUILD_TYPE on behalf of the CMakeLists.txt file. Of
course, you should document that variable and urge your project's
users to not directly use CMAKE_BUILD_TYPE anymore; perhaps, you
should even hide the latter in a GUI by marking it as advanced.
With regard to CMAKE_INSTALL_PREFIX, you could do the same - or use
CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT, as a robust criterion,
to see whether the user has supplied a value explicitly. Note that
there're additional aspects to consider if the CMakeLists.txt file
is to write that variable's value to the cache, cf. [1] et seq.
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] CMake command line arguments
In order to build the project the users have to land on a doku page or
a README.FIRST anyway. There we can give the command instead of
documenting how this behaves with different generators. So I think
this is a good tradeoff.
On Mon, Mar 7, 2011 at 1:06 PM, Michael Hertling mhertl...@online.de wrote:
On 03/07/2011 12:37 PM, Gabriel Petrovay wrote:
Thanks for the tips, Michael.
We will do so, using project specific BUILD_TYPE and INSTALL_PREFIX.
However, the downside of this approach is that your project's users
should not refer to the well-known CMake variables CMAKE_BUILD_TYPE
and CMAKE_INSTALL_PREFIX anymore - possibly an issue to consider.
On Mon, Mar 7, 2011 at 12:20 PM, Michael Hertling mhertl...@online.de
wrote:
On 03/07/2011 11:33 AM, Michael Hertling wrote:
On 03/06/2011 12:12 PM, Gabriel Petrovay wrote:
Hi,
Is there a way to read the arguments that were passed to CMake from
inside a CMakeLists.txt file?
There is a problem that some generators (like NMake Makefiles) set a
default value for certain variables (like CMAKE_BUILD_TYPE=Debug,
CMAKE_INSTALL_PREFIX=C:\Program Files\${CMAKE_PROJECT_NAME})
From inside CMake one can not set up a different default value if the
user does not specify it with a -D option. This is because
IF(CMAKE_BUILD_TYPE) will always be true because of the default set by
the generator (NMake Makefiles).
There was this guy having the same problem:
http://www.mail-archive.com/cmake@cmake.org/msg09640.html
Any solution how one can solve this? Reading the arguments passed to
CMake would be one, but I find no documentation/example/google_result
for this.
Thanks!
Scanning the command line for user-supplied settings wouldn't be
reliable because your project might also be configured via a GUI.
Furthermore, even an empty CMAKE_BUILD_TYPE variable may denote a
valid build type, so there's no robust criterion to decide when to
set a default value by examining this variable alone. Instead, you
might use another variable, say ${PROJECT_NAME}_BUILD_TYPE, and do:
IF(NOT DEFINED ${PROJECT_NAME}_BUILD_TYPE)
SET(${PROJECT_NAME}_BUILD_TYPE CUSTOM)
ENDIF()
SET(CMAKE_BUILD_TYPE ${${PROJECT_NAME}_BUILD_TYPE})
Alternatively, you might do:
SET(${PROJECT_NAME}_BUILD_TYPE CUSTOM
CACHE STRING ${PROJECT_NAME} Build Type)
SET(CMAKE_BUILD_TYPE ${${PROJECT_NAME}_BUILD_TYPE})
So, you'll have at least your project's own build type in the cache -
and, thus, in the GUIs - along with the documenting comment while the
cached value of CMAKE_BUILD_TYPE is still not the one that's actually
used.
If you say
SET(CMAKE_BUILD_TYPE ${${PROJECT_NAME}_BUILD_TYPE}
CACHE STRING CMake Build Type FORCE)
here, the cached value of CMAKE_BUILD_TYPE will equal the value in the
current scope again. Obviously, I'm quite unconcentrated today... ;-)
In this way, an undefined ${PROJECT_NAME}_BUILD_TYPE results in a
default CMAKE_BUILD_TYPE on behalf of the CMakeLists.txt file. Of
course, you should document that variable and urge your project's
users to not directly use CMAKE_BUILD_TYPE anymore; perhaps, you
should even hide the latter in a GUI by marking it as advanced.
With regard to CMAKE_INSTALL_PREFIX, you could do the same - or use
CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT, as a robust criterion,
to see whether the user has supplied a value explicitly. Note that
there're additional aspects to consider if the CMakeLists.txt file
is to write that variable's value to the cache, cf. [1] et seq.
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
--
MSc Gabriel Petrovay
Mobile: +41(0)787978034
www.28msec.com
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] problem with Visual Studio 2010 and additional link flags
On 3/7/2011 1:14 AM, Rolf Eike Beer wrote: In my solution I have several samples, some of which are windows based while other are console based. So I need to be able to change the link flag /SUBSYSTEM:CONSOLE (or /SUBSYSTEM:WINDOWS) depending on the executable I'm building Am I missing something or is it a bug in the VS2010 generator ? (once again, it was working with 2008) You are missing the WIN32 argument to ADD_EXECUTABLE(). 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 Thanks that did the trick ___ 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] Documentation for CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT missing?
On Monday 07 March 2011, Johannes Zarl wrote: Hi, I just wanted to read the documentation on CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT, but discovered that the variable is not listed in the cmake docs. Is there a reason for this? It's an internal variable. Should I open a bugreport on it? No. 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] PREDEFINED_TARGETS_FOLDER and ALL_BUILD Target
I looked at the code and the possibility of introducing a policy to allow the alternate behavior. Looks quite straight forward, so I ask: What is the policy on adding policies? Aaron C. Meadows From: cmake-boun...@cmake.org [mailto:cmake-boun...@cmake.org] On Behalf Of Meadows, Aaron C. Sent: Friday, March 04, 2011 12:49 PM To: david.c...@kitware.com Cc: cmake@cmake.org Subject: Re: [CMake] PREDEFINED_TARGETS_FOLDER and ALL_BUILD Target Is there some reason that couldn't be a property as well? Or possibly a Policy? 2) why does ALL_BUILD need to be the default project - This one I can't answer. I don't understand why it even is the default startup project anyhow. As such, it's useless. It seems to me that your *main executable* target (although we do not have such a designation, one would be nice) should be the default startup project, so that F5 / menu Debug Start Debugging just works without having to manually set a startup project. Build Solution / F7 / Ctrl+Shift+B builds ALL_BUILD regardless of what the default startup project is. So, I wonder if someone would like to jump in on the Policy direction? Something like: CMP0018: Allow ALL_BUILDS target to be put into the same Solution Folder as other targets controled by the PREDEFINED_TARGETS_FOLDER property. Starting with CMake 2.8.5, enabling this policy will allow the ALL_BUILDS auto-generated target to be moved into a Solution Folder, controled by the PREDEFINED_TARGETS_FOLDER property. Enabling this policy will cause ALL_BUILDS to nolonger be automatically selected as the Default project in Visual Studio. This policy was introduced in CMake version 2.8.5. Use the cmake_policy command to set it to OLD or NEW explicitly. Seems like it wouldn't be so hard to do that, and would allow the (bizarre) old behavior while still allowing a more consistent behavior. Thoughts? This email was sent to you by Thomson Reuters, the global news and information company. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Thomson Reuters. This email was sent to you by Thomson Reuters, the global news and information company. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Thomson Reuters. ___ 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 and RPM packages
Any progress on it ? One more information, this n900-devel image uses internally qemu and I am not sure that can cause any issue for the build system. That is also interesting why the debian packaging worked just fine in the scratchbox using also qemu internally. Best Regards, Laszlo Papp On Mon, Mar 7, 2011 at 5:27 AM, Laszlo Papp djsz...@archlinux.us wrote: By the way, you can find here the gluon-*.rpm packages built by the OBS: http://repo.pub.meego.com/home:/sandst1/standard/armv7l/ http://repo.pub.meego.com/home:/sandst1/standard/i586/ (unpack it with rpm2cpio src.rpm | cpio -idmv) Those spec files are done by a packager (human), thus not automated by a generator. I am not sure it helps with anything after all, but I try to provide as much as I can. Best Regards, Laszlo Papp On Mon, Mar 7, 2011 at 2:33 AM, Laszlo Papp djsz...@archlinux.us wrote: On Sun, Mar 6, 2011 at 11:27 PM, Eric Noulard eric.noul...@gmail.com wrote: 2011/3/6 Laszlo Papp djsz...@archlinux.us: Mmh, my previous mail is blocked because the cpack.log is too big. http://djszapi.homelinux.net/rpmbuild.out http://djszapi.homelinux.net/rpmbuild.err http://djszapi.homelinux.net/cpack.log I do not quite understand what makes rpmbuild fail. Could you send me [a link to] the generated gluon.spec file. And could you show what are the INSTALL rules you use in the CMakeLists.txt for gluon_qtplayer and template.qml and Invaders_Assets_Material.gml http://djszapi.homelinux.net/gluon.spec http://djszapi.homelinux.net/template.qml.install http://djszapi.homelinux.net/qtplayer.install http://djszapi.homelinux.net/invaders_assets_material.gml.install = /usr/share/gluon/games/invaders.gluon/Assets/Invaders_Assets_Material.gml = under the invaders.gluon Best Regards, Laszlo Papp ___ 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] CMake command line arguments
Hi,
Try putting set(CMAKE_USER_MAKE_RULES_OVERRIDE MyCompilerFlags) before
project() command.
Then, override variable CMAKE_BUILD_TYPE_INIT (with plain unconditional set
command, without putting into cache) in MyCompilerFlags.cmake file (make
sure you put it into location CMake can reach).
Regards,
Yuri
2011/3/7 Gabriel Petrovay gabipetro...@gmail.com
This does not work because the NMake Makefile generator already sets
the variable: CMAKE_BUILD_TYPE to Debug
So your code will never be executed:
if(NOT CMAKE_BUILD_TYPE)
# it will never get here
set(CMAKE_BUILD_TYPE RelWithDebInfo)
endif(NOT CMAKE_BUILD_TYPE)
And I want to have a default of Release.
Gabriel
On Mon, Mar 7, 2011 at 3:14 AM, 徐亮 lxu4...@gmail.com wrote:
You can check if the variable has defined. You can see
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:if; for
detail information.
if(NOT CMAKE_BUILD_TYPE)
set(CMAKE_BUILD_TYPE RelWithDebInfo)
endif()
2011/3/7 Gabriel Petrovay gabipetro...@gmail.com
Hi,
I don't understand how to do that...
The user who builds does not set any environment and does not provide
any -D arguments. I want CMake to automatically configure variables
like: CMAKE_BUILD_TYPE or CMAKE_INSTALL_PREFIX when the user does not
provide them. So I want *my* default values. But I don't want to set
them when the user provides the *generator* (NMake Makefiles)
default values.
The only way I see it is for CMake to tell you what parameters were
there in the command line. Does CMake support this?
How do you do this with the PATH environment variable?
Gabriel
On Mon, Mar 7, 2011 at 2:41 AM, 徐亮 lxu4...@gmail.com wrote:
From: Gabriel Petrovay gabipetro...@gmail.com
Subject: [CMake] CMake command line arguments
Hi,
Is there a way to read the arguments that were passed to CMake from
inside a CMakeLists.txt file?
There is a problem that some generators (like NMake Makefiles) set
a
default value for certain variables (like CMAKE_BUILD_TYPE=Debug,
CMAKE_INSTALL_PREFIX=C:\Program Files\${CMAKE_PROJECT_NAME})
From inside CMake one can not set up a different default value if
the
user does not specify it with a -D option. This is because
IF(CMAKE_BUILD_TYPE) will always be true because of the default set
by
the generator (NMake Makefiles).
There was this guy having the same problem:
http://www.mail-archive.com/cmake@cmake.org/msg09640.html
Any solution how one can solve this? Reading the arguments passed to
CMake would be one, but I find no documentation/example/google_result
for this.
Thanks!
--
MSc Gabriel Petrovay
Mobile: +41(0)787978034
www.28msec.com
I use environment variables to handle this problem. Such as
$ENV{PATH}.
Liang Xu
___
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
--
MSc Gabriel Petrovay
Mobile: +41(0)787978034
www.28msec.com
--
Liang Xu
--
MSc Gabriel Petrovay
Mobile: +41(0)787978034
www.28msec.com
___
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
___
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 and RPM packages
2011/3/7 Laszlo Papp djsz...@archlinux.us:
Any progress on it ?
Nope.
I won't be very responsive this week.
One more information, this n900-devel image uses
internally qemu and I am not sure that can cause any issue for the
build system.
I don't like I said I'm not that experienced with cross-compiling env.
That is also interesting why the debian packaging worked just fine in
the scratchbox using also qemu internally.
Does the pb you are facing for RPM occur in the same scractchbox env?
If this repo corresponds to the same gluon:
http://gitorious.org/gluon/gluon/blobs/master/core/CMakeLists.txt
then those:
set(INCLUDE_INSTALL_DIR ${CMAKE_INSTALL_PREFIX}/include
CACHE PATH The subdirectory relative to the install prefix where
header files will be installed.)
set(LIB_INSTALL_DIR ${CMAKE_INSTALL_PREFIX}/lib${LIB_SUFFIX}
CACHE PATH The subdirectory relative to the install prefix where
libraries will be installed.)
set(SHARE_INSTALL_DIR ${CMAKE_INSTALL_PREFIX}/share
CACHE PATH The subdiractory relative to the install prefix where
data and other files will be installed.)
are not a good idea because after that you use _INSTALL_DIR as
DESTINATIOn of your
INSTALL(...) command which makes it use an ABSOLUTE_INSTALL PATH.
you shouldn't use ${CMAKE_INSTALL_PREFIX}/share but share which
would make it a relative path.
Is there any reason you use absolute destination path.
(this is probably not the culprit but this doesn't help either).
I'll try to examine the problem more in detail tomorrow.
--
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] CPack and RPM packages
On Mon, Mar 7, 2011 at 9:11 PM, Eric Noulard eric.noul...@gmail.com wrote: 2011/3/7 Laszlo Papp djsz...@archlinux.us: Any progress on it ? Nope. I won't be very responsive this week. That does not sound too good.. ! One more information, this n900-devel image uses internally qemu and I am not sure that can cause any issue for the build system. I don't like I said I'm not that experienced with cross-compiling env. Nobody told you are, I have been just trying to provide as much information as I can ... That is also interesting why the debian packaging worked just fine in the scratchbox using also qemu internally. Does the pb you are facing for RPM occur in the same scractchbox env? No, maemo/debian system (scratchbox) is a different story compared to the meego/rpm way. If this repo corresponds to the same gluon: http://gitorious.org/gluon/gluon/blobs/master/core/CMakeLists.txt No, it does not, and it is also mentioned on the main site by the kde-sysadmins so that do not use it because it is quite obsolete. It is a gitorious tragedy we cannot remove that from there. This is the current repository: https://projects.kde.org/projects/playground/games/gluon/repository Best Regards, Laszlo Papp ___ 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 and RPM packages
As said, the working OBS spec files can be found here: http://repo.pub.meego.com/home:/sandst1/standard/armv7l/ http://repo.pub.meego.com/home:/sandst1/standard/i586/ http://djszapi.homelinux.net/gluon.spec - this is the cpack/cmake generated one. Well, the cpack one doesn't really do anything, it only moves files around (and apparently requires some external calling code to move them into place). I don't know anything about cpack, just that the spec file you have there doesn't do anything except moving files around (and maybe package them if they happen to end up in the right place), but certianly not build anything. Best Regards, Laszlo Papp On Mon, Mar 7, 2011 at 9:16 PM, Laszlo Papp djsz...@archlinux.us wrote: On Mon, Mar 7, 2011 at 9:11 PM, Eric Noulard eric.noul...@gmail.com wrote: 2011/3/7 Laszlo Papp djsz...@archlinux.us: Any progress on it ? Nope. I won't be very responsive this week. That does not sound too good.. ! One more information, this n900-devel image uses internally qemu and I am not sure that can cause any issue for the build system. I don't like I said I'm not that experienced with cross-compiling env. Nobody told you are, I have been just trying to provide as much information as I can ... That is also interesting why the debian packaging worked just fine in the scratchbox using also qemu internally. Does the pb you are facing for RPM occur in the same scractchbox env? No, maemo/debian system (scratchbox) is a different story compared to the meego/rpm way. If this repo corresponds to the same gluon: http://gitorious.org/gluon/gluon/blobs/master/core/CMakeLists.txt No, it does not, and it is also mentioned on the main site by the kde-sysadmins so that do not use it because it is quite obsolete. It is a gitorious tragedy we cannot remove that from there. This is the current repository: https://projects.kde.org/projects/playground/games/gluon/repository Best Regards, Laszlo Papp ___ 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] QtCreator project generator
On Friday 04 March 2011, Campbell Barton wrote: On Thu, Mar 3, 2011 at 5:10 PM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: On Tuesday 01 March 2011, Campbell Barton wrote: On Tue, Mar 1, 2011 at 2:47 PM, Marcus D. Hanwell marcus.hanw...@kitware.com wrote: On Tue, Mar 1, 2011 at 9:15 AM, John Drescher dresche...@gmail.com wrote: On Tue, Mar 1, 2011 at 6:45 AM, Campbell Barton ideasma...@gmail.com wrote: QT-Creator which currently supports CMake by reading code::blocks project files. The problem with this is code::blocks project files don't write in #defines, so the IDE shows #ifdef's incorrecyly. What are they needed for ? Does CodeBlocks and/or QtCreator do syntax highlighting based on this information ? http://wiki.codeblocks.org/index.php?title=Project_file The QtCreator developer is open to suggestions how to improve the CMake integration. So, adding stuff to the CodeBlocks project should be ok. Is there already a tag like that for C::B project files ? I can not really find one. Alex Yep, QtCreator will act as code is commented if the define are not found, you can type of course but no auto-complete or syntax highlighting. I don't use code::blocks but suspect it doesn't work this way. From my previous mail, heres a patch to cmake's codeblocks generator. http://www.graphicall.org/ftp/ideasman42/code_blocks.diff If this was applied qtcreator could use the defines. So QtCreator parses the -D options and uses them ? If so, please add this to the cmake bug tracker as feature request. 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] CMake 2.8.4 -- FindITK.cmake fails to find ITK even when ITK_DIR is properly set.
My first subject line was Who decided to break FindITK.cmake in
2.8.4? but that isn't probably very tactful.
We have a whole bunch of projects that used to configure and build
just fine with CMake 2.8.3. With 2.8.4 they fail.
The error message we get is:
CMake Error at /opt/cmake-2.8.4-Darwin-universal/CMake
2.8-4.app/Contents/share/cmake-2.8/Modules/FindITK.cmake:52 (MESSAGE):
Please set ITK_DIR to the directory containing ITKConfig.cmake. This is
either the root of the build tree, or PREFIX/lib/InsightToolkit for an
installation.
Call Stack (most recent call first):
BuildScripts/CMakeCommonExternalDefinitions.cmake:23 (find_package)
CMakeLists.txt:70 (PACKAGE_NEEDS_ITK)
We DO set ITK_DIR at configure time, and I HAVE verified that
ITKConfig.cmake DOES exist in ${ITK_DIR}.
Looking at the difference between FindITK.cmake in 2.8.3 and 2.8.4 it
looks like someone replaced trusting the ITK_DIR variable and using it
directly if defined, with
FIND_PACKAGE(ITK QUIET NO_MODULE
NAMES ITK InsightToolkit CONFIGS ITKConfig.cmake)
Which doesn't work -- it appears to ignore ITK_DIR and doggedly insist
that it can't find ITK.
What gives?
___
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] Toolchain changes even though specified on the command line
I have several compilers setup on my box for various reasons. I definately know this shows up when building for mingw and using the wrong command prompt with say visual studio in the path, and gcc not in the path. First, I create a new build output directory go into that directory and run a command line that specifies -G MinGW Makefiles.. then run 'make install' and of course the project builds; and I keep this around for a long time and keep revisiting, every time running the full cmake command line specifying all the parameters I want to use; it looks something like this 'cmake -G MinGW Makefiles /sack -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=/build/mingw_mono32_sack_core -DNEED_FREETYPE=1 -DNEED_JPEG=1 -DNEED_PNG=1 -DNEED_ZLIB=1 -DBUILD_MONOLITHIC=1' Then in a command shell that has watcom as the environment; it has tools 'nmake' and 'cl' etc which are supposedly clones of microsoft for compatiblity. the following is the output M:\build\mingw\sack\mono32_corecmake -G MinGW Makefiles /sack -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=/build/mingw_mono32_sack_core -DNEED_FREETYPE=1 -DNEED_JPEG=1 -DNEED_PNG=1 -DNEED_ZLIB=1 DBUILD_MONOLITHIC=1 CMake Error: your RC compiler: windres was not found. Please set CMAKE_RC_COMPILER to a valid compiler path or name. -- Configuring incomplete, errors occurred! You have changed variables that require your cache to be deleted. Configure will be re-run and you may have to reset some variables. The following variables have changed: CMAKE_RC_COMPILER= c:/tools/unix/mingw/bin/windres.exe -- Generating done -- Build files have been written to: M:/build/mingw/sack/mono32_core M:\build\mingw\sack\mono32_coremake install -- Building for: Visual Studio 10 -- Check for working C compiler using: Visual Studio 10 -- Check for working C compiler using: Visual Studio 10 -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler using: Visual Studio 10... So now I realize my mistake and hit ctrl-C and go to the correct shell but now when I run the build process I get M:\build\mingw\sack\mono32_corecmake -G MinGW Makefiles /sack -DCMAKE_BUILD_TYPE=Debug DCMAKE_INSTALL_PREFIX=/build/mingw_mono32_sack_core -DNEED_FREETYPE=1 -DNEED_JPEG=1 -DNEED_PNG=1 -DNEED_ZLIB=1 DBUILD_MONOLITHIC=1 CMake Error: Error: generator : MinGW Makefiles Does not match the generator used previously: Visual Studio 10 Either remove the CMakeCache.txt file or choose a different binary directory. M:\build\mingw\sack\mono32_coremake install ... 1 -- Configuring done -- Generating done -- Build files have been written to: M:/build/mingw/sack/mono32_core Scanning dependencies of target sack_bag CMake Error: Directory Information file not found [ 1%] Building C object CMakeFiles/sack_bag.dir/src/deadstart/deadstart_list.c.obj '' is not recognized as an internal or external command, operable program or batch file. make[2]: *** [CMakeFiles/sack_bag.dir/src/deadstart/deadstart_list.c.obj] Error 1 make[1]: *** [CMakeFiles/sack_bag.dir/all] Error 2 make: *** [all] Error 2 --- So even though the makefiles were created with mingw, the cache got deleted because it can't find 'windres'; and is now allowed to configure for a different compiler than what was specified on the command line. I have to manually delete the CMakeCache.txt and start over; which causes a recompilation of the entire project. Maybe if the makefile output included the generator so it wouldn't just invoke cmake with no generator, allwoing cmake to choose an inappropriate generator for the output that already exists? I do note that since 'windres.exe' doesn't exist cmake deletes the CMakeCache.txt; maybe if it just didn't do that? ___ 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] Question about Project.xml file when using subprojects
I have been looking at this webpage:
http://www.kitware.com/products/html/CDashSubprojects.html. I have created a
Project.xml file to list my subprojects. Right now I am just trying to use
Project.xml to add subprojects to a dashboard. I am trying to submit the file
to the dashboard like so:
#Stuff
ctest_submit(FILES ${CTEST_BINARY_DIRECTORY}/Project.xml)
#Stuff
ctest_update()
ctest_configure()
ctest_submit(PARTS Update Configure)
ctest_build(BUILD ${CTEST_BINARY_DIRECTORY})
ctest_test(BUILD ${CTEST_BINARY_DIRECTORY})
I am getting this error:
Cannot create directory /Testing/Temporary
Cannot create log file: LastSubmit.log
Error when uploading file: /home/dizou/build_dir/Project.xml
Error message was: Couldn't resolve host ''
Problems when submitting via HTTP
If I comment out ctest_submit(FILES ${CTEST_BINARY_DIRECTORY}/Project.xml),
everything gets submitted to the dashboard ok.
Am I putting Project.xml in the wrong directory? Should I be putting the
command in a seperate script?
Thanks for the help.
Lockheed Martin / ARL CISD
Aberdeen Proving Ground, MD 21005
Phone: 410-278-7751
Email: di@us.army.mil
___
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 and RPM packages
Further news, I have just tried the rpm generation on my host system out and it worked like a charm, here are the logs: http://djszapi.homelinux.net/cpack_host.log http://djszapi.homelinux.net/gluon_host.spec I hope it helps with something... Best Regards, Laszlo Papp On Mon, Mar 7, 2011 at 9:29 PM, Laszlo Papp djsz...@archlinux.us wrote: As said, the working OBS spec files can be found here: http://repo.pub.meego.com/home:/sandst1/standard/armv7l/ http://repo.pub.meego.com/home:/sandst1/standard/i586/ http://djszapi.homelinux.net/gluon.spec - this is the cpack/cmake generated one. Well, the cpack one doesn't really do anything, it only moves files around (and apparently requires some external calling code to move them into place). I don't know anything about cpack, just that the spec file you have there doesn't do anything except moving files around (and maybe package them if they happen to end up in the right place), but certianly not build anything. Best Regards, Laszlo Papp On Mon, Mar 7, 2011 at 9:16 PM, Laszlo Papp djsz...@archlinux.us wrote: On Mon, Mar 7, 2011 at 9:11 PM, Eric Noulard eric.noul...@gmail.com wrote: 2011/3/7 Laszlo Papp djsz...@archlinux.us: Any progress on it ? Nope. I won't be very responsive this week. That does not sound too good.. ! One more information, this n900-devel image uses internally qemu and I am not sure that can cause any issue for the build system. I don't like I said I'm not that experienced with cross-compiling env. Nobody told you are, I have been just trying to provide as much information as I can ... That is also interesting why the debian packaging worked just fine in the scratchbox using also qemu internally. Does the pb you are facing for RPM occur in the same scractchbox env? No, maemo/debian system (scratchbox) is a different story compared to the meego/rpm way. If this repo corresponds to the same gluon: http://gitorious.org/gluon/gluon/blobs/master/core/CMakeLists.txt No, it does not, and it is also mentioned on the main site by the kde-sysadmins so that do not use it because it is quite obsolete. It is a gitorious tragedy we cannot remove that from there. This is the current repository: https://projects.kde.org/projects/playground/games/gluon/repository Best Regards, Laszlo Papp ___ 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] Documentation for CMAKE_INSTALL_PREFIX_INITIALIZED_TO_DEFAULT missing?
On Mon, Mar 7, 2011 at 7:03 PM, Alexander Neundorf a.neundorf-w...@gmx.net wrote: It's an internal variable. May we use it? Or is it not intended for users to use it? -- MSc Gabriel Petrovay Mobile: +41(0)787978034 www.28msec.com ___ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
Re: [CMake] CPack and RPM packages
2011/3/7 Laszlo Papp djsz...@archlinux.us: As said, the working OBS spec files can be found here: http://repo.pub.meego.com/home:/sandst1/standard/armv7l/ http://repo.pub.meego.com/home:/sandst1/standard/i586/ Not really, since binary RPMs do not contains the spec file, but I did find the spec file in src: http://repo.pub.meego.com/home:/sandst1/standard/src/ (within the src.rpm) http://djszapi.homelinux.net/gluon.spec - this is the cpack/cmake generated one. I have seen that one, and as I said many files seems to be installed with ABSOLUTE DESTINATION and end-up with a %config attribute. If they were installed with relative PATH this wouldn't be the case. Well, the cpack one doesn't really do anything, it only moves files around (and apparently requires some external calling code to move them into place). CPackRPM supposed CMake+build has already been run so CPackRPM generated spec file is a shortcutted one. I don't know anything about cpack, just that the spec file you have there doesn't do anything except moving files around (and maybe package them if they happen to end up in the right place), but certianly not build anything. Yes that's the expected behavior. You cannot (in your case) call CPack without calling CMake first. CMake + make will do the build before CPack get a chance to run. -- 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] CPack and RPM packages
Well: http://public.kitware.com/Bug/view.php?id=11595 That is fixed in cmake 2.8.4. Changelog: http://www.cmake.org/pipermail/cmake/2011-February/042839.html CPackRPM fix bug 0011595 : Can't generate RPMs (on FC11...) I am trying to build this version now on MeeGo since the available binary one is 2.8.3. But if it is fixed in 2.8.4, I wonder why you did not know it ? Best Regards, Laszlo Papp On Tue, Mar 8, 2011 at 12:31 AM, Eric Noulard eric.noul...@gmail.com wrote: 2011/3/7 Laszlo Papp djsz...@archlinux.us: As said, the working OBS spec files can be found here: http://repo.pub.meego.com/home:/sandst1/standard/armv7l/ http://repo.pub.meego.com/home:/sandst1/standard/i586/ Not really, since binary RPMs do not contains the spec file, but I did find the spec file in src: http://repo.pub.meego.com/home:/sandst1/standard/src/ (within the src.rpm) http://djszapi.homelinux.net/gluon.spec - this is the cpack/cmake generated one. I have seen that one, and as I said many files seems to be installed with ABSOLUTE DESTINATION and end-up with a %config attribute. If they were installed with relative PATH this wouldn't be the case. Well, the cpack one doesn't really do anything, it only moves files around (and apparently requires some external calling code to move them into place). CPackRPM supposed CMake+build has already been run so CPackRPM generated spec file is a shortcutted one. I don't know anything about cpack, just that the spec file you have there doesn't do anything except moving files around (and maybe package them if they happen to end up in the right place), but certianly not build anything. Yes that's the expected behavior. You cannot (in your case) call CPack without calling CMake first. CMake + make will do the build before CPack get a chance to run. -- 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] CPack and RPM packages
2011/3/8 Laszlo Papp djsz...@archlinux.us: Well: http://public.kitware.com/Bug/view.php?id=11595 That is fixed in cmake 2.8.4. Changelog: http://www.cmake.org/pipermail/cmake/2011-February/042839.html CPackRPM fix bug 0011595 : Can't generate RPMs (on FC11...) I am trying to build this version now on MeeGo since the available binary one is 2.8.3. But if it is fixed in 2.8.4, I wonder why you did not know it ? I do know this bug, I fixed it. I'm just a mere human being and I did not recognize your symptom as being the same as the refered bug. I am really sorry for the wasted time, yours and mine :-/. -- 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] CPack and RPM packages
On Tue, Mar 8, 2011 at 12:45 AM, Eric Noulard eric.noul...@gmail.com wrote: 2011/3/8 Laszlo Papp djsz...@archlinux.us: Well: http://public.kitware.com/Bug/view.php?id=11595 That is fixed in cmake 2.8.4. Changelog: http://www.cmake.org/pipermail/cmake/2011-February/042839.html CPackRPM fix bug 0011595 : Can't generate RPMs (on FC11...) I am trying to build this version now on MeeGo since the available binary one is 2.8.3. But if it is fixed in 2.8.4, I wonder why you did not know it ? I do know this bug, I fixed it. I'm just a mere human being and I did not recognize your symptom as being the same as the refered bug. I am really sorry for the wasted time, yours and mine :-/. No idea whether or not that will be the solution, but It is hilarious, I cannot run the cmake ../ properly on the version 2.8.4... I mean it always enters an endless loop at random point, but all the time. I heard qemu+cmake is scary, but still How can I build the newest version of the cmake ? Cmake freezes all the time from the shadow build directory It is more than quite /pesky/. Best Regards, Laszlo Papp ___ 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 and RPM packages
1st run: ca -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Looking for C++ include iostream -- Looking for C++ include iostream - found -- Check for STD namespace -- Check for STD namespace - found -- Check for ANSI scope -- Check for ANSI scope - found -- Check for sstream -- Check for sstream - found -- Looking for unsetenv -- Looking for unsetenv - found -- Looking for environ -- Looking for environ - not found. -- Checking whether header cstdio is available -- Checking whether header cstdio is available - yes -- Checking for Large File Support -- Checking for Large File Support - yes -- Checking whether STL classes are in std namespace -- Checking whether STL classes are in std namespace - yes -- Checking whether ANSI stream headers are available -- Checking whether ANSI stream headers are available - yes -- Checking whether ANSI streams are in std namespace -- Checking whether ANSI streams are in std namespace - yes -- Checking whether ANSI string stream is available -- Checking whether ANSI string stream is available - yes -- Checking whether header cstddef is available -- Checking whether header cstddef is available - yes -- Checking whether stl string has operator!= for char* -- Checking whether stl string has operator!= for char* - yes -- Checking whether stl has iterator_traits Deadlock-like feeling on the user side except that I can kill the process - 2nd run: -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Looking for C++ include iostream -- Looking for C++ include iostream - found -- Check for STD namespace -- Check for STD namespace - found -- Check for ANSI scope -- Check for ANSI scope - found -- Check for sstream Endless loop feeling again here. - 3rd run: cmake -DCMAKE_INSTALL_PREFIX=/usr .. -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Looking for C++ include iostream -- Looking for C++ include iostream - found -- Check for STD namespace -- Check for STD namespace - found -- Check for ANSI scope -- Check for ANSI scope - found -- Check for sstream -- Check for sstream - found -- Looking for unsetenv -- Looking for unsetenv - found -- Looking for environ -- Looking for environ - not found. -- Checking whether header cstdio is available -- Checking whether header cstdio is available - yes -- Checking for Large File Support -- Checking for Large File Support - yes -- Checking whether STL classes are in std namespace -- Checking whether STL classes are in std namespace - yes -- Checking whether ANSI stream headers are available -- Checking whether ANSI stream headers are available - yes -- Checking whether ANSI streams are in std namespace -- Checking whether ANSI streams are in std namespace - yes -- Checking whether ANSI string stream is available -- Checking whether ANSI string stream is available - yes -- Checking whether header cstddef is available -- Checking whether header cstddef is available - yes -- Checking whether stl string has operator!= for char* -- Checking whether stl string has operator!= for char* - yes -- Checking whether stl has iterator_traits -- Checking whether stl has iterator_traits - yes -- Checking whether stl has standard template allocator -- Checking whether stl has standard template allocator - yes -- Checking for rebind member of stl allocator -- Checking for rebind member of stl allocator - yes -- Checking for non-standard argument to stl allocator::max_size -- Checking for non-standard argument to stl allocator::max_size - no -- Checking whether stl containers support allocator objects. -- Checking whether stl containers support allocator objects. - yes -- Checking whether ios has binary openmode -- Checking whether ios has binary openmode - yes -- Checking whether is needed for template friends -- Checking whether is needed for template friends - yes -- Checking
Re: [CMake] CPack and RPM packages
2011/3/8 Laszlo Papp djsz...@archlinux.us: On Tue, Mar 8, 2011 at 12:45 AM, Eric Noulard eric.noul...@gmail.com wrote: 2011/3/8 Laszlo Papp djsz...@archlinux.us: Well: http://public.kitware.com/Bug/view.php?id=11595 That is fixed in cmake 2.8.4. Changelog: http://www.cmake.org/pipermail/cmake/2011-February/042839.html CPackRPM fix bug 0011595 : Can't generate RPMs (on FC11...) I am trying to build this version now on MeeGo since the available binary one is 2.8.3. But if it is fixed in 2.8.4, I wonder why you did not know it ? I do know this bug, I fixed it. I'm just a mere human being and I did not recognize your symptom as being the same as the refered bug. I am really sorry for the wasted time, yours and mine :-/. No idea whether or not that will be the solution, but It is hilarious, I cannot run the cmake ../ properly on the version 2.8.4... I mean it always enters an endless loop at random point, but all the time. I heard qemu+cmake is scary, but still I did never use such combination, I let other comment on that one. How can I build the newest version of the cmake ? Cmake freezes all the time from the shadow build directory It is more than quite /pesky/. Concerning CPackRPM main issue, would try to 1) backup the CMake 2.8.3 , CPackRPM.cmake file 2) Edit CPackRPM.cmake file and change: %install if [ -e $RPM_BUILD_ROOT ]; then mv \\@CPACK_TOPLEVEL_DIRECTORY\@/tmpBBroot/*\ $RPM_BUILD_ROOT else mv \\@CPACK_TOPLEVEL_DIRECTORY\@/tmpBBroot\ $RPM_BUILD_ROOT fi to %install if [ -e $RPM_BUILD_ROOT ]; then rm -rf $RPM_BUILD_ROOT fi mv \\@CPACK_TOPLEVEL_DIRECTORY\@/tmpBBroot\ $RPM_BUILD_ROOT then rerun cpack. -- 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] CMake hanging when run inside QEmu
Hi, I am starting a separate thread on this hanging issue. -- Forwarded message -- From: Laszlo Papp xx Date: 2011/3/8 Subject: Re: [CMake] CPack and RPM packages To: Eric Noulard eric.noul...@gmail.com Cc : CMake ML cmake@cmake.org 1st run: ca -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Looking for C++ include iostream -- Looking for C++ include iostream - found -- Check for STD namespace -- Check for STD namespace - found -- Check for ANSI scope -- Check for ANSI scope - found -- Check for sstream -- Check for sstream - found -- Looking for unsetenv -- Looking for unsetenv - found -- Looking for environ -- Looking for environ - not found. -- Checking whether header cstdio is available -- Checking whether header cstdio is available - yes -- Checking for Large File Support -- Checking for Large File Support - yes -- Checking whether STL classes are in std namespace -- Checking whether STL classes are in std namespace - yes -- Checking whether ANSI stream headers are available -- Checking whether ANSI stream headers are available - yes -- Checking whether ANSI streams are in std namespace -- Checking whether ANSI streams are in std namespace - yes -- Checking whether ANSI string stream is available -- Checking whether ANSI string stream is available - yes -- Checking whether header cstddef is available -- Checking whether header cstddef is available - yes -- Checking whether stl string has operator!= for char* -- Checking whether stl string has operator!= for char* - yes -- Checking whether stl has iterator_traits Deadlock-like feeling on the user side except that I can kill the process - 2nd run: -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Looking for C++ include iostream -- Looking for C++ include iostream - found -- Check for STD namespace -- Check for STD namespace - found -- Check for ANSI scope -- Check for ANSI scope - found -- Check for sstream Endless loop feeling again here. - 3rd run: cmake -DCMAKE_INSTALL_PREFIX=/usr .. -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Looking for C++ include iostream -- Looking for C++ include iostream - found -- Check for STD namespace -- Check for STD namespace - found -- Check for ANSI scope -- Check for ANSI scope - found -- Check for sstream -- Check for sstream - found -- Looking for unsetenv -- Looking for unsetenv - found -- Looking for environ -- Looking for environ - not found. -- Checking whether header cstdio is available -- Checking whether header cstdio is available - yes -- Checking for Large File Support -- Checking for Large File Support - yes -- Checking whether STL classes are in std namespace -- Checking whether STL classes are in std namespace - yes -- Checking whether ANSI stream headers are available -- Checking whether ANSI stream headers are available - yes -- Checking whether ANSI streams are in std namespace -- Checking whether ANSI streams are in std namespace - yes -- Checking whether ANSI string stream is available -- Checking whether ANSI string stream is available - yes -- Checking whether header cstddef is available -- Checking whether header cstddef is available - yes -- Checking whether stl string has operator!= for char* -- Checking whether stl string has operator!= for char* - yes -- Checking whether stl has iterator_traits -- Checking whether stl has iterator_traits - yes -- Checking whether stl has standard template allocator -- Checking whether stl has standard template allocator - yes -- Checking for rebind member of stl allocator -- Checking for rebind member of stl allocator - yes -- Checking for non-standard argument to stl allocator::max_size -- Checking for non-standard argument to stl allocator::max_size - no -- Checking whether stl containers support allocator objects. -- Checking whether stl
Re: [CMake] Question about Project.xml file when using subprojects
Are you calling ctest_start(Experimental) or ctest_start(Nightly) before
callng ctest_submit...?
On Mon, Mar 7, 2011 at 4:32 PM, Zou, Di (Cont, ARL/CISD) di@us.army.mil
wrote:
I have been looking at this webpage:
http://www.kitware.com/products/html/CDashSubprojects.html. I have created
a Project.xml file to list my subprojects. Right now I am just trying to use
Project.xml to add subprojects to a dashboard. I am trying to submit the
file to the dashboard like so:
#Stuff
ctest_submit(FILES ${CTEST_BINARY_DIRECTORY}/Project.xml)
#Stuff
ctest_update()
ctest_configure()
ctest_submit(PARTS Update Configure)
ctest_build(BUILD ${CTEST_BINARY_DIRECTORY})
ctest_test(BUILD ${CTEST_BINARY_DIRECTORY})
I am getting this error:
Cannot create directory /Testing/Temporary
Cannot create log file: LastSubmit.log
Error when uploading file: /home/dizou/build_dir/Project.xml
Error message was: Couldn't resolve host ''
Problems when submitting via HTTP
If I comment out ctest_submit(FILES
${CTEST_BINARY_DIRECTORY}/Project.xml), everything gets submitted to the
dashboard ok.
Am I putting Project.xml in the wrong directory? Should I be putting the
command in a seperate script?
Thanks for the help.
Lockheed Martin / ARL CISD
Aberdeen Proving Ground, MD 21005
Phone: 410-278-7751
Email: di@us.army.mil
___
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] CMake hanging when run inside QEmu
1) What is the hackaround to install the newest version on arm ? 2) What is the final solution ? I think there are severe thread issues debug output contains almost the same information as the normal, not much addition... Should I open a bugreport instead with critical priority ? Put it mildly, it is completely useless on this arm. Best Regards, Laszlo Papp On Tue, Mar 8, 2011 at 12:55 AM, Eric Noulard eric.noul...@gmail.com wrote: Hi, I am starting a separate thread on this hanging issue. -- Forwarded message -- From: Laszlo Papp xx Date: 2011/3/8 Subject: Re: [CMake] CPack and RPM packages To: Eric Noulard eric.noul...@gmail.com Cc : CMake ML cmake@cmake.org 1st run: ca -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Looking for C++ include iostream -- Looking for C++ include iostream - found -- Check for STD namespace -- Check for STD namespace - found -- Check for ANSI scope -- Check for ANSI scope - found -- Check for sstream -- Check for sstream - found -- Looking for unsetenv -- Looking for unsetenv - found -- Looking for environ -- Looking for environ - not found. -- Checking whether header cstdio is available -- Checking whether header cstdio is available - yes -- Checking for Large File Support -- Checking for Large File Support - yes -- Checking whether STL classes are in std namespace -- Checking whether STL classes are in std namespace - yes -- Checking whether ANSI stream headers are available -- Checking whether ANSI stream headers are available - yes -- Checking whether ANSI streams are in std namespace -- Checking whether ANSI streams are in std namespace - yes -- Checking whether ANSI string stream is available -- Checking whether ANSI string stream is available - yes -- Checking whether header cstddef is available -- Checking whether header cstddef is available - yes -- Checking whether stl string has operator!= for char* -- Checking whether stl string has operator!= for char* - yes -- Checking whether stl has iterator_traits Deadlock-like feeling on the user side except that I can kill the process - 2nd run: -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Looking for C++ include iostream -- Looking for C++ include iostream - found -- Check for STD namespace -- Check for STD namespace - found -- Check for ANSI scope -- Check for ANSI scope - found -- Check for sstream Endless loop feeling again here. - 3rd run: cmake -DCMAKE_INSTALL_PREFIX=/usr .. -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Looking for C++ include iostream -- Looking for C++ include iostream - found -- Check for STD namespace -- Check for STD namespace - found -- Check for ANSI scope -- Check for ANSI scope - found -- Check for sstream -- Check for sstream - found -- Looking for unsetenv -- Looking for unsetenv - found -- Looking for environ -- Looking for environ - not found. -- Checking whether header cstdio is available -- Checking whether header cstdio is available - yes -- Checking for Large File Support -- Checking for Large File Support - yes -- Checking whether STL classes are in std namespace -- Checking whether STL classes are in std namespace - yes -- Checking whether ANSI stream headers are available -- Checking whether ANSI stream headers are available - yes -- Checking whether ANSI streams are in std namespace -- Checking whether ANSI streams are in std namespace - yes -- Checking whether ANSI string stream is available -- Checking whether ANSI string stream is available - yes -- Checking whether header cstddef is available -- Checking whether header cstddef is available - yes -- Checking whether stl string has operator!= for char* -- Checking whether stl string has operator!=
Re: [CMake] Cmake with Cray Fortran
Hi guys, Good news -- the system admins are installing 2.8.4 on all the government Cray machines! Bad news -- I can't actually get anything to work. I pulled the git repo version and built the master branch because of what David pointed out. However, I cannot figure out how to make it actually link. I get errors on all my executables saying ftn-2191 crayftn: ERROR in command line ynamic is an invalid argument to the -r option. How can I get it to drop the -rdynamic option? Tim - Original Message - From: David Partyka david.part...@kitware.com To: Eric Noulard eric.noul...@gmail.com Cc: gtg0...@mail.gatech.edu, cmake@cmake.org Sent: Saturday, March 5, 2011 12:03:40 PM Subject: Re: [CMake] Cmake with Cray Fortran FYI, if you want to build static on cray, Brad just checked in a fix into CMake yesterday that addresses -Bdynamic link flags showing up in the link line even though you're trying to build static, often resulting in your executable prefering to link against shared system libraries rather than static. This was causing issues linking static while building ParaView on Jaguar. http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=5abfb571843dba949e010f3b2840d8882d0f3d73 On Sat, Mar 5, 2011 at 11:21 AM, Eric Noulard eric.noul...@gmail.com wrote: 2011/3/5 Tim Gallagher tim.gallag...@gatech.edu : Eric, Excellent! Thanks! I don't know a whole lot about CMake (yet) -- would it be possible to make older versions aware of the compiler if I were to package only the updated files rather than install my own version of CMake? In other words, was it something simple like changing the CMakeFortranCompilerId.F file and if so, could I tell another version of CMake to use my own copy of that file? I don't know I am not the author of the fix, I think Brad King was the one who did this, may be he will answer that. It would be a lot easier if I only had to make our users put a few extra files somewhere than have them all install their own version of CMake in their home directories on all these Cray machines. May be deploying CMake 2.8.4 globally on each machine and set up appropriate module would even be easier for the users? Or may be this is not an option because you don'thave administrative privilege on those machines? -- 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 ___ 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 and RPM packages
I could not still build cmake.. But I did this modification locally you suggested and that is the output: CPack: Create package using RPM CPack: Install projects CPack: - Run preinstall target for: Gluon CPack: - Install project: Gluon CPack: Create package CPackRPM: Will use GENERATED spec file: /home/meego/gluon/build/_CPack_Packages/Linux/RPM/SPECS/gluon.spec CPack: - package: /home/meego/gluon/build/Gluon-0.71.0.rpm.rpm generated. It was a quite slow process after the spec file generation, but it seems to work. I do really hope someone can fix the arm - qemu - cmake thread hanging issues otherwise no idea how to get this functionality working officially... Best Regards, Laszlo PApp On Tue, Mar 8, 2011 at 12:53 AM, Eric Noulard eric.noul...@gmail.com wrote: 2011/3/8 Laszlo Papp djsz...@archlinux.us: On Tue, Mar 8, 2011 at 12:45 AM, Eric Noulard eric.noul...@gmail.com wrote: 2011/3/8 Laszlo Papp djsz...@archlinux.us: Well: http://public.kitware.com/Bug/view.php?id=11595 That is fixed in cmake 2.8.4. Changelog: http://www.cmake.org/pipermail/cmake/2011-February/042839.html CPackRPM fix bug 0011595 : Can't generate RPMs (on FC11...) I am trying to build this version now on MeeGo since the available binary one is 2.8.3. But if it is fixed in 2.8.4, I wonder why you did not know it ? I do know this bug, I fixed it. I'm just a mere human being and I did not recognize your symptom as being the same as the refered bug. I am really sorry for the wasted time, yours and mine :-/. No idea whether or not that will be the solution, but It is hilarious, I cannot run the cmake ../ properly on the version 2.8.4... I mean it always enters an endless loop at random point, but all the time. I heard qemu+cmake is scary, but still I did never use such combination, I let other comment on that one. How can I build the newest version of the cmake ? Cmake freezes all the time from the shadow build directory It is more than quite /pesky/. Concerning CPackRPM main issue, would try to 1) backup the CMake 2.8.3 , CPackRPM.cmake file 2) Edit CPackRPM.cmake file and change: %install if [ -e $RPM_BUILD_ROOT ]; then mv \\@CPACK_TOPLEVEL_DIRECTORY\@/tmpBBroot/*\ $RPM_BUILD_ROOT else mv \\@CPACK_TOPLEVEL_DIRECTORY\@/tmpBBroot\ $RPM_BUILD_ROOT fi to %install if [ -e $RPM_BUILD_ROOT ]; then rm -rf $RPM_BUILD_ROOT fi mv \\@CPACK_TOPLEVEL_DIRECTORY\@/tmpBBroot\ $RPM_BUILD_ROOT then rerun cpack. -- 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-commits] CMake branch, master, updated. v2.8.4-129-gbe9af61
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, master has been updated via be9af61f723194d6efd5cf20254b8935e49b8bac (commit) from e92461bfb85af7d99ec6affc0002fe638135 (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=be9af61f723194d6efd5cf20254b8935e49b8bac commit be9af61f723194d6efd5cf20254b8935e49b8bac Author: KWSys Robot kwro...@kitware.com AuthorDate: Tue Mar 8 00:01:08 2011 -0500 Commit: KWSys Robot kwro...@kitware.com CommitDate: Tue Mar 8 00:10:31 2011 -0500 KWSys Nightly Date Stamp diff --git a/Source/kwsys/kwsysDateStamp.cmake b/Source/kwsys/kwsysDateStamp.cmake index f45c766..da7fede 100644 --- a/Source/kwsys/kwsysDateStamp.cmake +++ b/Source/kwsys/kwsysDateStamp.cmake @@ -18,4 +18,4 @@ SET(KWSYS_DATE_STAMP_YEAR 2011) SET(KWSYS_DATE_STAMP_MONTH 03) # KWSys version date day component. Format is DD. -SET(KWSYS_DATE_STAMP_DAY 07) +SET(KWSYS_DATE_STAMP_DAY 08) --- 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
