[cmake-developers] [CMake 0014284]: cmake generates a non-working rsp file: c++.exe: error: CreateProcess: No such file or directory
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14284 == Reported By:abma Assigned To: == Project:CMake Issue ID: 14284 Category: CMake Reproducibility:always Severity: block Priority: normal Status: new == Date Submitted: 2013-07-10 08:48 EDT Last Modified: 2013-07-10 08:48 EDT == Summary:cmake generates a non-working rsp file: c++.exe: error: CreateProcess: No such file or directory Description: when compiling spring rts on win32 with cmake and ninja (cmake.exe -G Ninja .) g++ fails when trying to link spring.exe: it compiles with MinGW Makefiles. when i run g++ without invoking ninja i get the same error too. Steps to Reproduce: http://springrts.com/wiki/Building_Spring_on_Windows#Compiling_with_MinGW.2BCMake but use ninja. Additional Information: D:\springninja engine-legacy [1/2] Running utility command for generateVersionFiles Spring engine version: 94.1.1-693-g5717870 develop () [2/2] Linking CXX executable spring.exe FAILED: cmd.exe /c cd . D:\MinGW32\bin\c++.exe -mwindows-fopenmp -std=gnu++11 -march=i686 -msse -mfpmath=sse -mno-sse2 -mno -sse3 -mno-ssse3 -mno-sse4.1 -mno-sse4.2 -mno-sse4 -mno-sse4a -mno-avx -mno-fma -mno-fma4 -mno-xop -mno-lwp -mno-avx2 -fsingle-precision-con stant -frounding-math -mieee-fp -pipe -fno-strict-aliasing -mthreads -O2 -DNDEBUG -g -fopenmp -lgomp -Wl,--enable-auto-import -Wl,- -large-address-aware @CMakeFiles/engine-legacy.rsp -o spring.exe -Wl,--out-implib,rts\builds\legacy\libspring.dll.a -Wl,--major-image-versi on,0,--minor-image-version,0 cd . c++.exe: error: CreateProcess: No such file or directory ninja: build stopped: subcommand failed. == Issue History Date ModifiedUsername FieldChange == 2013-07-10 08:48 abma New Issue 2013-07-10 08:48 abma File Added: engine-legacy.rsp == -- 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] Semi-colons in COMPILE_DEFINITIONS
On 07/10/2013 08:52 AM, Stephen Kelly wrote: The problem is revealed because I changed GetCompileDefinitions to populate an out-vector instead of returning a string, which the VS generator used to use directly. The use of ExpandListArguments does not handle the 'escaped' semicolon. Should it be taught to? The problem is that now you're calling ExpandListArguments twice. The old code did: - targetOptions.AddDefines(target.GetCompileDefinitions(configName).c_str()); and the implementation of AddDefines calls ExpandListArguments. The new code does: + target.GetCompileDefinitions(targetDefines, configName); which runs ExpandListArguments internally too. Then you re-compose a ;-list without re-escaping the semicolons and pass it to + targetOptions.AddDefines(targetDefinesString.c_str()); which does ExpandListArguments again. BTW, the get-then-append pattern used in hunks like this: + std::vectorstd::string targetDefines; + target.GetCompileDefinitions(targetDefines, + this-ConfigurationName.c_str()); + this-AppendDefines(defines, targetDefines); should be refactored to use a helper rather than duplicated. For example, I was able to reduce a lot of code recently: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=d221eac8 Thanks, -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Semi-colons in COMPILE_DEFINITIONS
On 07/10/2013 09:04 AM, Brad King wrote: The new code does: + target.GetCompileDefinitions(targetDefines, configName); which runs ExpandListArguments internally too. Then you re-compose a ;-list without re-escaping the semicolons and pass it to + targetOptions.AddDefines(targetDefinesString.c_str()); which does ExpandListArguments again. I think the simplest fix is to add a cmIDEOptions::AddDefines overload that operates directly on the vector of strings. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] target sources property
On 07/09/2013 11:30 AM, Stephen Kelly wrote: Brad King brad.king@... writes: On 06/07/2013 09:13 AM, Stephen Kelly wrote: SOURCES $$CONFIG:Debug:other.cpp That has been requested as a feature occasionally. I'm not sure it is possible to implement on all the generators though. I just checked the VS 6, 9 and 11 IDEs and it is possible to mark a source file as excluded from certain configurations. Those versions represent all the VS generators. I do not see an obvious way to do it in Xcode though :( I looked into this a bit and pushed target-SOURCES-property to my clone. The sources would necessarily be config-specific if they are going to depend on the linked libraries. Can you think of any way around that? No. IIRC we have the same problem with inter-target dependencies and we solved it by taking the union of dependencies from all configs. Is that right? I don't think that solution can work for source files. Perhaps for Xcode we can generate wrapper sources that conditionally #include the real source based on the configuration. Hopefully there is a better way. BTW, the hunk -this-SetProperty(SOURCES, ss.str().c_str()); +this-SetProperty(SOURCES_INTERNAL, ss.str().c_str()); +return this-GetProperty(SOURCES_INTERNAL); does not need to set an internal property. We can just return the string. The only reason the old code set the property was to fall through to the normal property lookup later in the method. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
[cmake-developers] Automatic -F addition for frameworks?
Hi,
I've been looking into a patch to add an include directory automatically
when a framework is used. For example:
target_link_libraries(sometarget LINK_PRIVATE ${FOO})
if ${FOO}/.. is a framework path, then add ${FOO}/.. to the
INCLUDE_DIRECTORIES of sometarget (at generate time).
This means that if I use
target_link_libraries(sometarget
LINK_PUBLIC /path/to/prefix/lib/QtCore.framework/QtCore)
I can use #include QtCore/QString without using any addtional commands to
add include directories. That is true transitively because I used
LINK_PUBLIC in the above example. Each dependent target will add the
framework path to its own INCLUDE_DIRECTORIES.
Of course, using Qt5Core for this example does not make sense because a
more-useful IMPORTED target is provided for that.
This idea came from
http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/7260/focus=7283
The question is whether this is a worthwhile feature for cmake?
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Deprecating qt4_use_modules and qt4_automoc?
Stephen Kelly steveire@... writes: We could also probably add a runtime warning if enabled. You need to enable deprecation warnings with your compiler, so it would make sense to have to enable them with a cmake script too. CMAKE_ENABLE_DEPRECATION_WARNINGS could be used to determine whether to print a warning in the implementation of a macro or function. Comments? Bump! http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/6002/focus=6004 Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] target sources property
Brad King wrote: IIRC we have the same problem with inter-target dependencies and we solved it by taking the union of dependencies from all configs. Is that right? Yes, I think that's right. I don't think that solution can work for source files. Perhaps for Xcode we can generate wrapper sources that conditionally #include the real source based on the configuration. Hopefully there is a better way. That doesn't sound very attractive indeed. BTW, the hunk -this-SetProperty(SOURCES, ss.str().c_str()); +this-SetProperty(SOURCES_INTERNAL, ss.str().c_str()); +return this-GetProperty(SOURCES_INTERNAL); does not need to set an internal property. We can just return the string. The only reason the old code set the property was to fall through to the normal property lookup later in the method. Yes, but I guess it's also memory management. I can't return str.c_str() if str is an automatic variable. I guess I can use the trick of creating a static std::string and return that. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] target sources property
On 07/10/2013 11:12 AM, Stephen Kelly wrote: Yes, but I guess it's also memory management. I can't return str.c_str() if str is an automatic variable. I guess I can use the trick of creating a static std::string and return that. Oh, right. I'd rather not expose that to projects that might try to abuse SOURCES_INTERNAL for something. Elsewhere IIRC we have C++ class member variables specifically for this purpose. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMAKE_INSTALL_PREFIX vs CMAKE_SYSROOT ?
Brad King wrote:
On 7/4/2013 4:29 AM, Stephen Kelly wrote:
I can't think of anything that can be done with CMAKE_FIND_ROOT_PATH
which can't be done with CMAKE_PREFIX_PATH (with a bit more repetition on
the command line, I think). Should we enumerate the use cases to consider
documenting it obsolete?
One could have several roots in which target-arch packages
are installed. CMAKE_FIND_ROOT_PATH can list all of them.
The others are not lists.
I don't understand. CMAKE_PREFIX_PATH is a list.
If the install prefix is outside the sysroot,
This seems like a reasonable use case that should have full support.
Isn't your Goals example exactly this?
Yes, it is.
We already have
$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/${install_dest}
Goals:
* Install to /opt/kf5 on the target
* Install to $HOME/dev/kf5 on the host
What values should be used for CMAKE_INSTALL_PREFIX and DESTDIR?
It appears we need several values:
* Prefix on host for host-arch binaries ($HOME/host/kf5? not above)
* Prefix on host for target-arch binaries ($HOME/dev/kf5 above)
* Prefix on target for target-arch binaries (/opt/kf5 above)
* Toolchain sysroot on host (CMAKE_SYSROOT)
Without teaching CMake which targets belong to which category I
do not see how this can be done without project-specific values.
Even if we simplify and only install one target library (and build nothing
for the host), I don't know what values are appropriate. If I set
CMAKE_INSTALL_PREFIX - /opt/kf5
DESTDIR - $HOME/dev/kf5
then the library will end up in
$HOME/dev/kf5/opt/kf5/lib
instead of
$HOME/dev/kf5/lib
right?
Should the latter be supported?
Thanks,
Steve.
--
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Automatic -F addition for frameworks?
Brad King wrote: IIUC currently real library paths like foo.framework/foo have no special handling right now. They are (correctly) not split and there is no include directory added for them. Correct. So, the question is: do we want to add *new* special handling for library paths inside frameworks to also add include directories? Yep. I think this makes sense as long as it is only for raw paths and not imported targets (which can solve this with usage reqs). Yes. Any project depending on this will already have platform-specific code to #include with the framework name. Yes. I'm not familiar enough with mac or frameworks myself to know how useful or 'expected' this new behavior would be? Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] Automatic -F addition for frameworks?
On 07/10/2013 11:21 AM, Stephen Kelly wrote: Brad King wrote: Any project depending on this will already have platform-specific code to #include with the framework name. Yes. I'm not familiar enough with mac or frameworks myself to know how useful or 'expected' this new behavior would be? Clinton can give the final word on this but in Xcode one simply drags the framework into the dependencies list to get both include directories and linking. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMAKE_INSTALL_PREFIX vs CMAKE_SYSROOT ?
Brad King wrote: On 07/10/2013 11:17 AM, Stephen Kelly wrote: Brad King wrote: On 7/4/2013 4:29 AM, Stephen Kelly wrote: I can't think of anything that can be done with CMAKE_FIND_ROOT_PATH which can't be done with CMAKE_PREFIX_PATH (with a bit more repetition on the command line, I think). Should we enumerate the use cases to consider documenting it obsolete? One could have several roots in which target-arch packages are installed. CMAKE_FIND_ROOT_PATH can list all of them. The others are not lists. I don't understand. CMAKE_PREFIX_PATH is a list. Oops, I misread it as CMAKE_INSTALL_PREFIX for some reason. Anyway, IIUC CMAKE_FIND_ROOT_PATH can be used to map *all* searches with CMAKE_FIND_ROOT_PATH_MODE_LIBRARY=ONLY, not just those whose locations come from CMAKE_PREFIX_PATH, no? Yes, but I think Alex' point was that even the CMAKE_FIND_ROOT_PATH_MODE_LIBRARY=ONLY case can be done by using particular values in the CMAKE_PREFIX_PATH. However, that won't exclude the default paths in the root prefix, so I guess that's where CMAKE_FIND_ROOT_PATH is not replacable. To install to $HOME/dev/kf5 on the host then CMAKE_INSTALL_PREFIX should be $HOME/dev/kf5 currently. What is wrong with that? Any project-specific place that needs to know the on-target path can use a project-specific variable. Yes, I suppose. What I was suggesting was to standardise that. CMake-generated export files are relocatable and do not even know the original install prefix Right, but the program may need it hardcoded for whatever reason. In the case of Qt, several installation paths are hardcoded. For unit tests which are to be run on the target, there may be reasons to hardcode the installation path too. (except for the /lib-/usr/lib symlink hack, is this all for that?). Nope, this is really not about that. However, if the deployment location is /usr/lib, but the install prefix is $HOME/dev/kf5, then the hack will not be generated in the export files. If the target is running Arch or Fedora (or possibly Gentoo, which I believe is doing the same), that could be a problem. Thanks, Steve. -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMAKE_INSTALL_PREFIX vs CMAKE_SYSROOT ?
Stephen Kelly wrote: Nope, this is really not about that. I mean 'not really', but it's also part of the story. 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
[cmake-developers] [CMake 0014285]: Codeblocks generator needs to be more friendly towards project file.
The following issue has been SUBMITTED. == http://public.kitware.com/Bug/view.php?id=14285 == Reported By:Neil Darlow Assigned To: == Project:CMake Issue ID: 14285 Category: CMake Reproducibility:always Severity: feature Priority: normal Status: new == Date Submitted: 2013-07-10 12:33 EDT Last Modified: 2013-07-10 12:33 EDT == Summary:Codeblocks generator needs to be more friendly towards project file. Description: The CMake Codeblocks generator is a great tool but it appears to assume ownership of the generated project file. It is common for Codeblocks plugins (e.g. Doxyblocks and wxSmith) to insert content into the project file. This information needs to be preserved when e.g. CMake-gui regenerates the cache. At present it appears that the project file is completely rewritten when CMake-gui performs a cache regenerate operation. Steps to Reproduce: 1. Create e.g. a Codeblocks - MinGW Makefiles project with CMake-gui 2. Open the project in Codeblocks and add some content with wxSmith plugin 3. If you wish, build the project 4. Close the Project 5. Regenerate the CMake cache with CMake-gui 6. Open the project in Codeblocks and notice that wxSmith added resources are no longer present in the project tree Additional Information: I am using CMake-2.8.11.2 under Windows with Codeblocks-12.11 Although I specified Codeblocks - MinGW Makefiles I suspect it might affect other Codeblocks generator features I have reverted to using the MinGW Makefiles generator to ensure that my Codeblocks project file customisations are kept == Issue History Date ModifiedUsername FieldChange == 2013-07-10 12:33 Neil DarlowNew Issue == -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
Re: [cmake-developers] CMAKE_INSTALL_PREFIX vs CMAKE_SYSROOT ?
On 07/10/2013 12:05 PM, Stephen Kelly wrote: However, that won't exclude the default paths in the root prefix, so I guess that's where CMAKE_FIND_ROOT_PATH is not replacable. Yes. Any project-specific place that needs to know the on-target path can use a project-specific variable. Yes, I suppose. What I was suggesting was to standardise that. Okay, but I'd rather keep CMAKE_INSTALL_PREFIX to mean where on the host it will be installed since that's what make install will do. It is much simpler to preserve the existing role than to add a new variable to replace that role so that the existing variable can be used for a different role. The target environment's prefix is a separate concept, there could be more than one target environment, and it may not even make sense on some targets (e.g. those without a traditional filesystem). If we want to standardize this it will have to be something new. I think it is better to let projects do their own thing for a while and wait for conventions to develop instead of trying to predict all the use cases and standardize now. (except for the /lib-/usr/lib symlink hack, is this all for that?). Nope, this is really not about that. However, if the deployment location is /usr/lib, but the install prefix is $HOME/dev/kf5, then the hack will not be generated in the export files. If the target is running Arch or Fedora (or possibly Gentoo, which I believe is doing the same), that could be a problem. If that problem manifests in practice we can add a special hook to enable the workaround. Perhaps by then enough experience will have been gained that we can look at standardizing the target prefix values as discussed above. -Brad -- Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
