| Summary: | Qyoto: Could not find CMakeCSharpCompiler.cmake with cmake 2.8.10 | ||
|---|---|---|---|
| Product: | [Unmaintained] bindings | Reporter: | Andrea Scarpino <scarpino> |
| Component: | general | Assignee: | kde-bindings |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | aacid, arno, dpldobrev, rdieter, stupor_scurvy343 |
| Priority: | NOR | ||
| Version: | 4.9 | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | suggested fix from kde-packager/kde-buildsystem list | ||
|
Description
Andrea Scarpino
2012-11-06 13:53:14 UTC
This seems to be some regression or behavior change in cmake. Per our downstream report, https://bugzilla.redhat.com/show_bug.cgi?id=872829 Kevin suggests... (yet untested): CMakeCSharpCompiler.cmake is configured from CMakeCSharpCompiler.cmake.in by this command: configure_file(${script_dir}/CMakeCSharpCompiler.cmake.in ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}/CMakeCSharpCompiler.cmake IMMEDIATE @ONLY) in cmake/CMakeDetermineCSharpCompiler.cmake. It looks like the hardcoded destination path there needs to be adjusted for CMake 2.8.10, e.g.: if (${CMAKE_VERSION} VERSION_LESS "2.8.10") set (COMPILER_SUPPORT_SUBDIRECTORY "") else (${CMAKE_VERSION} VERSION_LESS "2.8.10") set (COMPILER_SUPPORT_SUBDIRECTORY "/${CMAKE_VERSION}") endif (${CMAKE_VERSION} VERSION_LESS "2.8.10") configure_file(${script_dir}/CMakeCSharpCompiler.cmake.in ${CMAKE_BINARY_DIR}${CMAKE_FILES_DIRECTORY}${COMPILER_SUPPORT_SUBDIRECTORY}/CMakeCSharpCompiler.cmake IMMEDIATE @ONLY) Thanks for the bug report. I reproduced it with 2.8.10 on Windows too. I can take a look later. In the mean time, as a workaround just copy CMakeCSharpCompiler.cmake from assemblygen/bin/CMakeFiles to assemblygen/bin/CMakeFiles/2.8.10 and it will work. Created attachment 75060 [details]
suggested fix from kde-packager/kde-buildsystem list
Works as advertised for me on fedora 18
Rex, Thanks for the patch. However, you seem to have created it from https://projects.kde.org/projects/kde/kdebindings/csharp/qyoto. This repository is obsolete and should not be used. The only reason it is not deleted are KDE release policies. The new repository is https://projects.kde.org/projects/kde/kdebindings/csharp/assemblygen/repository. Please, apply the patch there and I'll commit it. Actually it needs to be applied in both repositories. 'qyoto' is still part of the released packages and has to build. If this fixes the regression for everybody, I'll apply the patch there. Err, "This repository is obsolete and should not be used"??? WTF do you mean? this is the repository we are releasing, if this is not to be released i'd appreciate you guys dropped by the release-team list and coordinated a bit with the world. Because you can do the better stuff in the world but if it's not released, what is the point of doing it? Slightly off-topic: The "new" version is binary and source incompatible with the old qyoto. So simply replacing it is a no-go. Assemblygen itself was only moved to KDE git about a week ago (was on gitorious before) and we haven't talked to the release team about it yet. Personally, I'd prefer some cleanup and repo splitting before the 'new' Qyoto gets released regularly and packaged. ok, so it's a "in development" stuff, thanks for the clarification :-) Are you guys going to commit this or what? Today we are packaging 4.10 beta 1 and will have the same problem Fixed in master and 4.9. Sorry for the delay. The patch doesn't work for the new Qyoto so I can't fix it right now. But it's not yet included in the build anyway, |