Re: [cmake-developers] Odd behaviour in VS14 (Visual studio 2015)
Brad, I had a look at the .vcxproj files and there is no trace of odd paths in there. I realise now that I have #include statements of the kind #include And clearly it is VS that is appending these unixy paths to the (correct) cmake generated path prefix for the project etc. It appears to be a VS problem rather than a cmake one. I will investigate elsewhere. Thanks for the suggestion and sorry for the noise. JB On 11/09/15 20:15, "Brad King" <brad.k...@kitware.com> wrote: >On 09/11/2015 08:38 AM, Biddiscombe, John A. wrote: >> I have been having problems with projects in VS14 and it appears >> to be caused by the generation of paths used by/in the IDE >> >> D:\Code\hvtkm\vtkm\vtkm/worklet/GaussianSplatter.h >> >> whereas it used to always be >> >> D:\Code\hvtkm\vtkm\vtkm\worklet\GaussianSplatter.h > >Please provide a minimal test project that shows this behavior. >Also please show a snippet of the .vcxproj content that has >such slashes. > >Thanks, >-Brad > -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
[cmake-developers] Odd behaviour in VS14 (Visual studio 2015)
Using cmake 3.3.1 I have been having problems with projects in VS14 and it appears to be caused by the generation of paths used by/in the IDE D:\Code\hvtkm\vtkm\vtkm/worklet/GaussianSplatter.h whereas it used to always be D:\Code\hvtkm\vtkm\vtkm\worklet\GaussianSplatter.h Note the forwardslash instead of backslash in the latest IDE The result is that when you click on an error, the window opens up a 'new' copy of the file and changes you make in it are not always picked up, syntax highlighting, debug watches/vars don't work and I've lost quite a bit of work by having 'N' copies of the file open and saved one without realising another was open multiple times with changes in. I will submit a bug report, but before I do, has anyone else noticed this (I'm afraid I don't follow the list very thoroughly and my quick check on mantis revealed nothing). I suspect I'm doing something wrong, so though I'd ask before creating an issue... thanks JB -- John Biddiscombe,email:biddisco @.at.@ cscs.ch http://www.cscs.ch/ CSCS, Swiss National Supercomputing Centre | Tel: +41 (91) 610.82.07 Via Trevano 131, 6900 Lugano, Switzerland | Fax: +41 (91) 610.82.82 -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake 2.8.11-rc3 ready for testing!
May I ask one question related to the Target Usage Requirements ... For HDF5 (for example), the user might enable Parallel IO, which requires MPI. When enabled, the hdf5 cmakelists use find_package to get MPI and all is fine. Users of hdf5 might not know that they are using an hdf which has parallel IO enabled, and compilation is complicated by the unexpected dependency on mpi libs and includes Is this new feature designed to resolve this long standing irritation so that when installed, the hdf5 will add the mpi dependency behind the scenes? If so, I am delighted and would like to test it out on the hdf5 distribution. If there is a link to an example I can copy from, please say. Thanks JB -Original Message- From: cmake-developers-boun...@cmake.org [mailto:cmake-developers-boun...@cmake.org] On Behalf Of Robert Maynard Sent: 19 April 2013 15:24 To: cmake-developers@cmake.org Subject: [cmake-developers] CMake 2.8.11-rc3 ready for testing! The CMake 2.8.11 release candidate continues. This is the last RC unless a critical, must-fix issue is found. You can find the source and binaries here: http://www.cmake.org/files/v2.8/?C=M;O=D Some of the notable changes in this release are: - Introduced Target Usage Requirements - Targets can specify usage requirements for their consumers such as include directories and preprocessor definitions; previously only link dependencies were supported - target_link_libraries(myexe yourlib) can now build myexe sources with requirements specified by yourlib - Added target_include_directories and target_compile_definitions commands with PUBLIC/PRIVATE/INTERFACE options - See design and development discussion at http://community.kde.org/Frameworks/Epics/CMake_target_usage_requirements - Introduced a Generator Toolset selection for VS = 10 and Xcode = 3 - Tell the IDEs which compiler toolchain to use - ex. Use VS 9 tools under VS 10: -G Visual Studio 10 -T v90 - Introduced ExternalData Module - Keep source trees lightweight by storing data separately - Reference data unambiguously from source tree by content hash - Fetch on-demand during build from local or remote resources - CMake: Sublime Text Generator added that supports both Make and Ninja - CMake: Added support for Texas Instruments C6 and up compilers - CMake: Improve OpenBSD support - CMake: Support for Windows CE with VS 8 and 9 generators - CPack: Added Support for 64bit NSIS - CPack: Added WiX Package Generator - ExternalProject: Will run git fetch less often - FindBoost: Major overhaul of searching and result caching - FindCUDA: Now has support for separable compilation - FindQt4: Overall improvements to finding Qt and importing targets - FindSquish: Added support for squish 4 - GetPrerequisites: Port to MinGW with objdump The bug tracker change log page for this version is at: http://public.kitware.com/Bug/changelog_page.php?version_id=103 Following is the complete list of changes in this rc since the previous rc. Please try this version of CMake on your projects and report any issues to the list or the bug tracker. This release candidate will become the final release for 2.8.11 unless a serious issue is reported. Changes in CMake 2.8.11-rc3 (since 2.8.11-rc2) -- Brad King (1): get_filename_component: Document path components more clearly (#14091) Rolf Eike Beer (1): try_compile: add missing fclose() to recently added error case Stephen Kelly (1): Fix clearing of the INCLUDE_DIRECTORIES DIRECTORY property. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake 2.8.11-rc3 ready for testing!
One important extra point. The MPI library was NOT built with cmake, but the HDF5 and the user's project would be. Not sure if that makes a difference JB From: Biddiscombe, John A. Sent: 22 April 2013 16:46 To: 'Stephen Kelly'; cmake-developers@cmake.org Subject: RE: [cmake-developers] CMake 2.8.11-rc3 ready for testing! Sorry, I assumed too much familiarity with hdf5/mpi Hdf5 has CMakelists.txt files and declares a number of targets. When built with parallel IO, hdf5 used find_package(MPI) to get the required libs and includes for the library to compile and link nicely with mpi. No problem When you do a make install on hdf5, it creates a set of very nice cmake files C:\Program Files\hdf5-1.8.11\cmake\hdf5\hdf5-targets.cmake C:\Program Files\hdf5-1.8.11\cmake\hdf5\hdf5-targets-debug.cmake C:\Program Files\hdf5-1.8.11\cmake\hdf5\hdf5-targets-release.cmake C:\Program Files\hdf5-1.8.11\cmake\hdf5\hdf5-config.cmake C:\Program Files\hdf5-1.8.11\cmake\hdf5\hdf5-config-version.cmake Which declare imported targets for debug and release and do everything right. Except that if the user picks up HDF5 using the syntax find_package(HDF5 NO_MODULE) i.e. NOT using the findhdf5 (because we want to pick up the cmake config) then the user's project has a 'hidden' dependency on mpi includes and libs and unless they add a find_package(mpi) to their project - and add the necessary include dirs. And links - theit build will fail What I'd like to di, is in the target import declared by hdf5, add in this transitive link dependency to m pi. In the past I was advised not to do this, but my hope is that this can be expressed nicely with the new syntax Yes? JB -Original Message- From: cmake-developers-boun...@cmake.orgmailto:cmake-developers-boun...@cmake.org [mailto:cmake-developers-boun...@cmake.org] On Behalf Of Stephen Kelly Sent: 22 April 2013 16:35 To: cmake-developers@cmake.orgmailto:cmake-developers@cmake.org Subject: Re: [cmake-developers] CMake 2.8.11-rc3 ready for testing! Biddiscombe, John A. wrote: May I ask one question related to the Target Usage Requirements ... For HDF5 (for example), the user might enable Parallel IO, which requires MPI. When enabled, the hdf5 cmakelists use find_package to get MPI and all is fine. Hi there, I am not familiar with hdf5 or mpi. What are you referring to when you say the hdf5 cmakelists ? Do you mean FindHDF5.cmake? Users of hdf5 might not know that they are using an hdf which has parallel IO enabled, and compilation is complicated by the unexpected dependency on mpi libs and includes Can you be specific about what is more complicated? I'm not familiar with what is complicated. Is this new feature designed to resolve this long standing irritation so that when installed, the hdf5 will add the mpi dependency behind the scenes? Sort of/maybe. It is designed for use with IMPORTED targets, which in general means that the upstream uses CMake and installs a Config.cmake file. As there is a FindHDF5.cmake, I'm guessing that is not the case here. However, it would be possible to create IMPORTED targets in the Find file. However, there may be other ways of solving the problems you're experiencing regarding convenience, even without these features. Using these features has certain conveniences, but they don't seem to be what you're after. What you're after seems to be possible anyway. PNG_LIBRARIES contains ZLIB_LIBRARY for example, because it depends on it. Should HDF5_LIBRARIES contain MPI_LIBRARIES? Sorry I can't give more useful information. Maybe someone else can. Thanks, Steve. -- Powered by www.kitware.comhttp://www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMake 2.8.11-rc3 ready for testing!
Sorry, I assumed too much familiarity with hdf5/mpi Hdf5 has CMakelists.txt files and declares a number of targets. When built with parallel IO, hdf5 used find_package(MPI) to get the required libs and includes for the library to compile and link nicely with mpi. No problem When you do a make install on hdf5, it creates a set of very nice cmake files C:\Program Files\hdf5-1.8.11\cmake\hdf5\hdf5-targets.cmake C:\Program Files\hdf5-1.8.11\cmake\hdf5\hdf5-targets-debug.cmake C:\Program Files\hdf5-1.8.11\cmake\hdf5\hdf5-targets-release.cmake C:\Program Files\hdf5-1.8.11\cmake\hdf5\hdf5-config.cmake C:\Program Files\hdf5-1.8.11\cmake\hdf5\hdf5-config-version.cmake Which declare imported targets for debug and release and do everything right. Except that if the user picks up HDF5 using the syntax find_package(HDF5 NO_MODULE) i.e. NOT using the findhdf5 (because we want to pick up the cmake config) then the user's project has a 'hidden' dependency on mpi includes and libs and unless they add a find_package(mpi) to their project - and add the necessary include dirs. And links - theit build will fail What I'd like to di, is in the target import declared by hdf5, add in this transitive link dependency to m pi. In the past I was advised not to do this, but my hope is that this can be expressed nicely with the new syntax Yes? JB -Original Message- From: cmake-developers-boun...@cmake.org [mailto:cmake-developers-boun...@cmake.org] On Behalf Of Stephen Kelly Sent: 22 April 2013 16:35 To: cmake-developers@cmake.org Subject: Re: [cmake-developers] CMake 2.8.11-rc3 ready for testing! Biddiscombe, John A. wrote: May I ask one question related to the Target Usage Requirements ... For HDF5 (for example), the user might enable Parallel IO, which requires MPI. When enabled, the hdf5 cmakelists use find_package to get MPI and all is fine. Hi there, I am not familiar with hdf5 or mpi. What are you referring to when you say the hdf5 cmakelists ? Do you mean FindHDF5.cmake? Users of hdf5 might not know that they are using an hdf which has parallel IO enabled, and compilation is complicated by the unexpected dependency on mpi libs and includes Can you be specific about what is more complicated? I'm not familiar with what is complicated. Is this new feature designed to resolve this long standing irritation so that when installed, the hdf5 will add the mpi dependency behind the scenes? Sort of/maybe. It is designed for use with IMPORTED targets, which in general means that the upstream uses CMake and installs a Config.cmake file. As there is a FindHDF5.cmake, I'm guessing that is not the case here. However, it would be possible to create IMPORTED targets in the Find file. However, there may be other ways of solving the problems you're experiencing regarding convenience, even without these features. Using these features has certain conveniences, but they don't seem to be what you're after. What you're after seems to be possible anyway. PNG_LIBRARIES contains ZLIB_LIBRARY for example, because it depends on it. Should HDF5_LIBRARIES contain MPI_LIBRARIES? Sorry I can't give more useful information. Maybe someone else can. Thanks, Steve. -- Powered by www.kitware.comhttp://www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] hdf5 dependency on mpi (was: CMake 2.8.11-rc3 ready for testing!)
Brad, Stephen OK. I can add the find_package to the hdf5-config.cmake But the user still has to add the include path to their own projects, and link each target against mpi. Paraview, for example, fails to build when you link against a system hdf5 which has parallel enabled. You have to manually change about 5 different cmakelists files to get it to work, if the hdf5_config, transitively added the link, it'd be much nicer. Can I add the #include and link into the hdf5-config.cmake? This is what I was advised not to do before. I can't find the advice on google, but will try harder if you really want it JB -Original Message- From: cmake-developers-boun...@cmake.org [mailto:cmake-developers-boun...@cmake.org] On Behalf Of Stephen Kelly Sent: 22 April 2013 17:13 To: cmake-developers@cmake.org Subject: Re: [cmake-developers] hdf5 dependency on mpi (was: CMake 2.8.11-rc3 ready for testing!) Brad King wrote: On 04/22/2013 10:46 AM, Biddiscombe, John A. wrote: C:\Program Files\hdf5-1.8.11\cmake\hdf5\hdf5-config.cmake find_package(HDF5 NO_MODULE) then the user’s project has a ‘hidden’ dependency on mpi In similar cases (in VTK and ITK) we have the package config file do find_package() for transitive dependencies. One may pre-populate any cache entries that the find module needs using the results from the original build tree (assuming the dependency does not move). I was going to suggest the same. The C:\Program Files\hdf5-1.8.11\cmake\hdf5\hdf5-config.cmake file should contain find_package(mpi), if that is needed. The new features do not provide a new way to solve this problem AFAIK. As far as I understand the issue, I agree. Even if the new features were used for another reason, the need for the find_package would still be there. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] hdf5 dependency on mpi
I think I hit the wrong key and my email disappeared, apologies if you get this twice The package config file should have only declarative effects and not actually modify the loading project's build, so that advice was correct. Understood. This seems sensible. The _INCLUDE_DIRS, _LIBRARIES, etc. variables that hdf5-config.cmake provides should already be populated with the transitive dependencies. It should be able to do this without find_package(MPI) too. OK, that's great. I've been doing this in my builds but thought it was somehow 'wrong' in the public release. Since hdf5 already knows which mpi libs/includes are being pulled in, all is ok. One thing : Suppose hdf5 pulls in the mpi lib and includes, and the project using it requests mpi separately. Is there a correct - or standard - way of making sure the user does not choose a different mpi lib - If we know that the project using hdf5 will call find_package(MPI) then we could too in the config, and that'd actually be a good way of making sure the same one is used. If the calling project does need or use mpi itself, it can/would just confuse the user... Is there a correct way of handling this? (I'm guessing the best we can do is export a variable HDF5_MPI_INCLUDE etc etc which the user can test if concerned that the user mpi doesn't match the hdf5 mpi) Thanks again JB -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] VS2010 fortran composer
I'm trying to get the entire hdf5 project compiling with the fortran stuff
enabled, but I've run into an issue
The solution has mixed fortran and c targets, and it adds dependency
information which includes the project file extension
cmVisualStudio10TargetGenerator::WriteProjectReferences ...
if (dt-GetProperty(Fortran_MODULE_DIRECTORY))
{
path += .vfproj;
}
else {
path += .vcxproj;
}
I added the .vfproj clause to try to get the h5fortran_detect projects to be
classed as vfproj (otherwise the custom rules which generate .f90 files don't
run it seems - I'm still trying to work out exactly what's wrong, but this is
one guess)...
Anyway the dt-GetProperty(Fortran_MODULE_DIRECTORY) always returns true,
even if one of the C projects is the target - because it is globally for the
cmake project.
What I need is a if target_link_language == fortran (or if target is
fortrantarget) then use this extension, otherwise ...
How can I test if one of the individual targets is using fortran of not.
My best guess so far is to add a method to cmTarget to iterate over source
files and test their extensions individually, but I'm sure there must be a
correct way of doing it.
TIA
JB
Git fortrancomposerbranch pushed to
git://git.cscs.ch/cmake.git
it's only my test hack to get stuff working, I'll clean it up once I am
confident that I can build complex projects.
___
cmake-developers mailing list
cmake-developers@cmake.org
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] VS2010 fortran composer
if(cmTarget::LinkInterface const* iface = dt-GetLinkInterface(Debug))
{
if (iface-Languages.size()0 iface-Languages[0]==Fortran)
{
path += .vfproj;
}
Seems to work.
-Original Message-
From: cmake-developers-boun...@cmake.org
[mailto:cmake-developers-boun...@cmake.org] On Behalf Of Biddiscombe, John A.
Sent: 18 March 2011 14:19
Cc: cmake-developers@cmake.org
Subject: Re: [cmake-developers] VS2010 fortran composer
I'm trying to get the entire hdf5 project compiling with the fortran stuff
enabled, but I've run into an issue
The solution has mixed fortran and c targets, and it adds dependency
information which includes the project file extension
cmVisualStudio10TargetGenerator::WriteProjectReferences ...
if (dt-GetProperty(Fortran_MODULE_DIRECTORY))
{
path += .vfproj;
}
else {
path += .vcxproj;
}
I added the .vfproj clause to try to get the h5fortran_detect projects to be
classed as vfproj (otherwise the custom rules which generate .f90 files don't
run it seems - I'm still trying to work out exactly what's wrong, but this is
one guess)...
Anyway the dt-GetProperty(Fortran_MODULE_DIRECTORY) always returns true,
even if one of the C projects is the target - because it is globally for the
cmake project.
What I need is a if target_link_language == fortran (or if target is
fortrantarget) then use this extension, otherwise ...
How can I test if one of the individual targets is using fortran of not.
My best guess so far is to add a method to cmTarget to iterate over source
files and test their extensions individually, but I'm sure there must be a
correct way of doing it.
TIA
JB
Git fortrancomposerbranch pushed to
git://git.cscs.ch/cmake.git
it's only my test hack to get stuff working, I'll clean it up once I am
confident that I can build complex projects.
___
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
If I create a cpp project with the IDE it goes into x64/Debug/blah, adding fortran makes no difference and they both go into x64/Debug/blah If I create a cpp project using cmake, it goes into debug/blah, adding a fortran one puts the fortran one in x64/debug/blah, but the cpp one stays behind. I didn't try linking them. If I remove the overridden OUTDIR=/debug/blah from the cmake generated project, then the cpp goes into x64/debug/blah as expected. How do I change cmake_intdir. I will be happy to just use x64/etc for everything JB -Original Message- From: Bill Hoffman [mailto:bill.hoff...@kitware.com] Sent: 10 March 2011 23:03 To: Biddiscombe, John A. Cc: cmake-developers@cmake.org Subject: Re: VS2010 fortran composer On 3/10/2011 4:36 PM, Biddiscombe, John A. wrote: If you create a new cpp project, by default it is win32 and visual studio puts everything in debug/... If you change platform to x64, then it goes into x64/debug/... even without any fortran stuff added. Adding fortran doesn't change anything. No, if you create a visual studio x64 CMake project it does not do that. You have to use the Visual Studio 9 2008 Win64 generator to start with. JB -Original Message- From: Bill Hoffman [mailto:bill.hoff...@kitware.com] Sent: 10 March 2011 21:53 To: Biddiscombe, John A. Cc: cmake-developers@cmake.org Subject: Re: VS2010 fortran composer On 3/10/2011 3:09 PM, Biddiscombe, John A. wrote: Contrary to what I might have previously said ...(not sure if I did, but) ... AFAICT if the cpp and fortran projects are all x64 configuration then everything goes into x64/Debug or x64/Release. (Mixing win32 and win64 causes trouble, but we don't care about that) So, mixing win32 and win64 is not something we support. I find it odd that by adding the fortran libs into the mix it changes existing C libraries. What if you do this: 1. create a c/C++ project with CMake (no x64). 2. Load that project into the IDE 3. Add a fortran library What happens? Did it change the C/C++ locations or the fortran one? So changing CMAKE_INTDIR to x64/etc ought to be allowed yes? If so, where does it happen - or rather where can I do it? JB -Original Message- From: Bill Hoffman [mailto:bill.hoff...@kitware.com] Sent: 10 March 2011 20:03 To: Biddiscombe, John A. Cc: cmake-developers@cmake.org Subject: Re: VS2010 fortran composer On 3/10/2011 1:48 PM, Biddiscombe, John A. wrote: It also has to match CMAKE_INTDIR, or tons of stuff will not work. Can I change CMAKE_INTDIR from the generator since the fortran stuff uses its own location (mostly)? It has to be consistent with the C/C++ for mixed language projects. What happens if you create a project in the IDE and have a C/C++ library, and a fortran library? Does it put the libraries in different directories? Can you have an executable that links to both the C and fortran, how does that work? Are you doing this in a public git repo somewhere? Not yet, but when I'm back from vacation, I'll setup on that you can access. OK, sounds good, if you could investigate the above that would be good. JB -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoff...@kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] VS2010 fortran composer
Contrary to what I might have previously said ...(not sure if I did, but) ... AFAICT if the cpp and fortran projects are all x64 configuration then everything goes into x64/Debug or x64/Release. (Mixing win32 and win64 causes trouble, but we don't care about that) So changing CMAKE_INTDIR to x64/etc ought to be allowed yes? If so, where does it happen - or rather where can I do it? JB -Original Message- From: Bill Hoffman [mailto:bill.hoff...@kitware.com] Sent: 10 March 2011 20:03 To: Biddiscombe, John A. Cc: cmake-developers@cmake.org Subject: Re: VS2010 fortran composer On 3/10/2011 1:48 PM, Biddiscombe, John A. wrote: It also has to match CMAKE_INTDIR, or tons of stuff will not work. Can I change CMAKE_INTDIR from the generator since the fortran stuff uses its own location (mostly)? It has to be consistent with the C/C++ for mixed language projects. What happens if you create a project in the IDE and have a C/C++ library, and a fortran library? Does it put the libraries in different directories? Can you have an executable that links to both the C and fortran, how does that work? Are you doing this in a public git repo somewhere? Not yet, but when I'm back from vacation, I'll setup on that you can access. OK, sounds good, if you could investigate the above that would be good. JB -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoff...@kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] VS2010 fortran composer
If you create a new cpp project, by default it is win32 and visual studio puts everything in debug/... If you change platform to x64, then it goes into x64/debug/... even without any fortran stuff added. Adding fortran doesn't change anything. JB -Original Message- From: Bill Hoffman [mailto:bill.hoff...@kitware.com] Sent: 10 March 2011 21:53 To: Biddiscombe, John A. Cc: cmake-developers@cmake.org Subject: Re: VS2010 fortran composer On 3/10/2011 3:09 PM, Biddiscombe, John A. wrote: Contrary to what I might have previously said ...(not sure if I did, but) ... AFAICT if the cpp and fortran projects are all x64 configuration then everything goes into x64/Debug or x64/Release. (Mixing win32 and win64 causes trouble, but we don't care about that) So, mixing win32 and win64 is not something we support. I find it odd that by adding the fortran libs into the mix it changes existing C libraries. What if you do this: 1. create a c/C++ project with CMake (no x64). 2. Load that project into the IDE 3. Add a fortran library What happens? Did it change the C/C++ locations or the fortran one? So changing CMAKE_INTDIR to x64/etc ought to be allowed yes? If so, where does it happen - or rather where can I do it? JB -Original Message- From: Bill Hoffman [mailto:bill.hoff...@kitware.com] Sent: 10 March 2011 20:03 To: Biddiscombe, John A. Cc: cmake-developers@cmake.org Subject: Re: VS2010 fortran composer On 3/10/2011 1:48 PM, Biddiscombe, John A. wrote: It also has to match CMAKE_INTDIR, or tons of stuff will not work. Can I change CMAKE_INTDIR from the generator since the fortran stuff uses its own location (mostly)? It has to be consistent with the C/C++ for mixed language projects. What happens if you create a project in the IDE and have a C/C++ library, and a fortran library? Does it put the libraries in different directories? Can you have an executable that links to both the C and fortran, how does that work? Are you doing this in a public git repo somewhere? Not yet, but when I'm back from vacation, I'll setup on that you can access. OK, sounds good, if you could investigate the above that would be good. JB -- Bill Hoffman Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 bill.hoff...@kitware.com http://www.kitware.com 518 881-4905 (Direct) 518 371-3971 x105 Fax (518) 371-4573 ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] VS2010 fortran composer
OK, that is odd... Is there a way to change that in the project files that you generate? Seems like it would be odd for the C/C++ stuff to end up in Debug, and the fortran to be in X64/Debug... It does not appear to be something I can control. 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
Thanks
It's a bit of a hack, but testing for the target name and overriding the output
path seems to work.
This gets me past the trycompile step so now projects are being generated from
scratch.
if (this-Name==cmTryCompileExec) {
std::string path =
cmsys::SystemTools::GetFilenamePath(this-PathToVcxproj);
(*this-BuildFileStream ) OutputFile=\
cmsys::SystemTools::ConvertToWindowsOutputPath(path.c_str()).c_str()
\\ this-Name .exe\/\n;
}
else {
(*this-BuildFileStream ) /\n;
}
I'll stick with this for now - if there's a better way I'll no doubt find out
eventually ...
JB
From: Bill Hoffman [mailto:bill.hoff...@kitware.com]
Sent: 09 March 2011 13:54
To: Biddiscombe, John A.
Cc: cmake-developers@cmake.org
Subject: Re: RE: VS2010 fortran composer
http://software.intel.com/en-us/forums/showthread.php?t=80773
That Guy seemed to change it...
sent from my phone
On Mar 9, 2011 4:29 AM, Biddiscombe, John A.
biddi...@cscs.chmailto:biddi...@cscs.ch wrote:
OK, that is odd... Is there a way to change that in the project files
that you generate?
Seems like it would be odd for the C/C++ stuff to end up in Debug, and
the fortran to be in X64/Debug...
It does not appear to be something I can control.
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
Using devenv.com, we're making progress - but the binary produced by CMakeDetermineCompilerABI is in debug/bin and it's not looking there - does the devenv do it differently from msbuild? JB C:\cmakebuild\fortrantestC:\cmakebuild\cmake\bin\Debug\cmake.exe c:\Code\fortrantest -G Visual Studio 10 Win64 --debug-trycompile --debug -output debug trycompile on Running with debug output on. -- Check for working Fortran compiler using: Visual Studio 10 Win64 Called from: [2] C:/Code/cmake/Modules/CMakeTestFortranCompiler.cmake [1] c:/Code/fortrantest/CMakeLists.txt -- Check for working Fortran compiler using: Visual Studio 10 Win64 -- works Called from: [2] C:/Code/cmake/Modules/CMakeTestFortranCompiler.cmake [1] c:/Code/fortrantest/CMakeLists.txt -- Detecting Fortran compiler ABI info Called from: [2] C:/Code/cmake/Modules/CMakeTestFortranCompiler.cmake [1] c:/Code/fortrantest/CMakeLists.txt CMake Error at C:/Code/cmake/Modules/CMakeDetermineCompilerABI.cmake:31 (TRY_COMPILE): Cannot copy output executable '' to destination specified by COPY_FILE: 'C:/cmakebuild/fortrantest/CMakeFiles/CMakeDetermineCompilerABI_Fortran.bin' Unable to find the executable at any of: C:/cmakebuild/fortrantest/CMakeFiles/CMakeTmp/cmTryCompileExec.exe C:/cmakebuild/fortrantest/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec.exe C:/cmakebuild/fortrantest/CMakeFiles/CMakeTmp/Development/cmTryCompileExec.exe Call Stack (most recent call first): C:/Code/cmake/Modules/CMakeTestFortranCompiler.cmake:59 (CMAKE_DETERMINE_COMPILER_ABI) CMakeLists.txt:2 (project) ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] VS2010 fortran composer
CMakeFiles\CMakeTmp\x64\Debug\cmTryCompileExec.exe Apologies for the time lag, not at work this week. I realize I made a mistake in the last post, it's the x64 in the path that's throwing it off. JB -Original Message- From: Bill Hoffman [mailto:bill.hoff...@kitware.com] Sent: 08 March 2011 14:22 To: Biddiscombe, John A. Cc: cmake-developers@cmake.org Subject: Re: VS2010 fortran composer On 3/8/2011 6:41 AM, Biddiscombe, John A. wrote: Using devenv.com, we're making progress - but the binary produced by CMakeDetermineCompilerABI is in debug/bin and it's not looking there - does the devenv do it differently from msbuild? JB C:\cmakebuild\fortrantestC:\cmakebuild\cmake\bin\Debug\cmake.exe c:\Code\fortrantest -G Visual Studio 10 Win64 --debug-trycompile --debug -output debug trycompile on Running with debug output on. -- Check for working Fortran compiler using: Visual Studio 10 Win64 Called from: [2] C:/Code/cmake/Modules/CMakeTestFortranCompiler.cmake [1] c:/Code/fortrantest/CMakeLists.txt -- Check for working Fortran compiler using: Visual Studio 10 Win64 -- works Called from: [2] C:/Code/cmake/Modules/CMakeTestFortranCompiler.cmake [1] c:/Code/fortrantest/CMakeLists.txt -- Detecting Fortran compiler ABI info Called from: [2] C:/Code/cmake/Modules/CMakeTestFortranCompiler.cmake [1] c:/Code/fortrantest/CMakeLists.txt CMake Error at C:/Code/cmake/Modules/CMakeDetermineCompilerABI.cmake:31 (TRY_COMPILE): Cannot copy output executable '' to destination specified by COPY_FILE: 'C:/cmakebuild/fortrantest/CMakeFiles/CMakeDetermineCompilerABI_Fortran.bin' Unable to find the executable at any of: C:/cmakebuild/fortrantest/CMakeFiles/CMakeTmp/cmTryCompileExec.exe C:/cmakebuild/fortrantest/CMakeFiles/CMakeTmp/Debug/cmTryCompileExec.exe C:/cmakebuild/fortrantest/CMakeFiles/CMakeTmp/Development/cmTryCompileExec.exe Call Stack (most recent call first): C:/Code/cmake/Modules/CMakeTestFortranCompiler.cmake:59 (CMAKE_DETERMINE_COMPILER_ABI) CMakeLists.txt:2 (project) Where exactly is cmTryCompileExec.exe after the command is run? ___ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[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] 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
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
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
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
