Overview
Loading...
Request History
wolfi323 created request
- Use %cmake and %cmake_install macros
Fixes build error with latest cmake in Factory/Tumbleweed
("CMake Error: No source or binary directory provided")
cgiboudeaux accepted request
Although correct, that just hides the issue with the latest CMake (if that's the cause for the build issue)
Well, explicitly specifying the source dir on the cmake command line (which the macro does amongst other things) is one way to fix the issue. (the other one would be to set it in CMakeLists.txt itself, but why should we patch that if not necessary?)
From the cmake 3.13.4 changelog (where the error has been downgraded to a warning):
"Scripts relying on the old behavior can be trivially fixed by specifying the path to the source tree (even if just .) explicitly and continue to work with all versions of CMake."
It also builds fine if I just change it to "cmake $EXTRA_FLAGS .", but the usage of the macro should be preferred anyway, no?
Btw, I think it's actually wrong to call cmake without a directory anyway, isn't it?
$ cmake --help
Usage
cmake [options] <path-to-source>
cmake [options] <path-to-existing-build>
Specify a source directory to (re-)generate a build system for it in the
current working directory. Specify an existing build directory to
re-generate its build system.
And that's actually what this error message and the 3.13.3 changelog entry tells:
CMake now checks that at least one of the source or binary directory is specified when running CMake and issues an error if both are missing. This has always been a documented requirement, but the implementation previously accidentally accepted cases in which neither are specified so long as some other argument is given, and silently used the current working directory as the source and build tree.
So it only worked before by accident because of the $EXTRA_FLAGS... ;-)
yes, the spec file wasn't following the recommended way.
In fact it didn't follow the required way, and only happened to work due to a bug in cmake (that's been fixed in 3.13.3).
So at least it's clear now that this change doesn't "hide" any issue, it was the cmake call in the spec file that was wrong all along.