Changeset View
Standalone View
plugins/cmake/cmakeutils.cpp
| Show First 20 Lines • Show All 316 Lines • ▼ Show 20 Line(s) | |||||
| 317 | 317 | | |||
| 318 | QString currentBuildType( KDevelop::IProject* project, int builddir ) | 318 | QString currentBuildType( KDevelop::IProject* project, int builddir ) | ||
| 319 | { | 319 | { | ||
| 320 | return readBuildDirParameter( project, Config::Specific::cmakeBuildTypeKey, QStringLiteral("Release"), builddir ); | 320 | return readBuildDirParameter( project, Config::Specific::cmakeBuildTypeKey, QStringLiteral("Release"), builddir ); | ||
| 321 | } | 321 | } | ||
| 322 | 322 | | |||
| 323 | QString findExecutable() | 323 | QString findExecutable() | ||
| 324 | { | 324 | { | ||
| 325 | auto cmake = QStandardPaths::findExecutable(QStringLiteral("cmake")); | 325 | auto cmake = QStandardPaths::findExecutable(QStringLiteral("cmake")); | ||
kfunk: This is also cumbersome, it would make sense in case CMake is shipped (or bundled with)… | |||||
| 326 | #ifdef Q_OS_WIN | 326 | #ifdef Q_OS_WIN | ||
| 327 | if (cmake.isEmpty()) | 327 | if (cmake.isEmpty()) | ||
| 328 | cmake = QStandardPaths::findExecutable(QStringLiteral("cmake"), { | 328 | cmake = QStandardPaths::findExecutable(QStringLiteral("cmake"), { | ||
| 329 | QStringLiteral("C:\\Program Files (x86)\\CMake\\bin"), | 329 | QStringLiteral("C:\\Program Files (x86)\\CMake\\bin"), | ||
| 330 | QStringLiteral("C:\\Program Files\\CMake\\bin"), | 330 | QStringLiteral("C:\\Program Files\\CMake\\bin"), | ||
| 331 | QStringLiteral("C:\\Program Files (x86)\\CMake 2.8\\bin"), | 331 | QStringLiteral("C:\\Program Files (x86)\\CMake 2.8\\bin"), | ||
| 332 | QStringLiteral("C:\\Program Files\\CMake 2.8\\bin")}); | 332 | QStringLiteral("C:\\Program Files\\CMake 2.8\\bin")}); | ||
| 333 | #endif | 333 | #endif | ||
I'd be fine with a fallback: #elif Q_OS_MAC
if (cmake.isEmpty())
cmake = QStandardPaths::findExecutable(QStringLiteral("cmake"), {"/opt/local/bin"}) // for CMake from MacPorts... here, though. kfunk: I'd be fine with a fallback:
```
#elif Q_OS_MAC
if (cmake.isEmpty())
cmake =… | |||||
For MacPorts it would have to be the 1st option. I think though that MacPorts isn't the only packaging system that installs to a parallel prefix and intends everything from there to override whatever the host already provides. Gentoo Prefix and pkgsrc come to mind. rjvbb: For MacPorts it would have to be the 1st option.
I think though that MacPorts isn't the only… | |||||
Then the system-wide PATH should already contain that prefix; this should not be within KDevelop's responsibility. Further note: We'd basically need to patch every QStandardPaths::findExecutable() call in order to make this a consistent behavior for all command-line tools inside KDevelop. kfunk: Then the system-wide PATH should already contain that prefix; this should not be within… | |||||
| 334 | return cmake; | 334 | return cmake; | ||
| 335 | } | 335 | } | ||
| 336 | 336 | | |||
| 337 | KDevelop::Path currentCMakeExecutable(KDevelop::IProject* project, int builddir) | 337 | KDevelop::Path currentCMakeExecutable(KDevelop::IProject* project, int builddir) | ||
| 338 | { | 338 | { | ||
| 339 | auto defaultCMakeExecutable = CMakeBuilderSettings::self()->cmakeExecutable().toLocalFile(); | 339 | auto defaultCMakeExecutable = CMakeBuilderSettings::self()->cmakeExecutable().toLocalFile(); | ||
| 340 | 340 | | |||
| 341 | if (!QFileInfo::exists(ICore::self()->runtimeController()->currentRuntime()->pathInHost(KDevelop::Path(defaultCMakeExecutable)).toLocalFile())) | 341 | if (!QFileInfo::exists(ICore::self()->runtimeController()->currentRuntime()->pathInHost(KDevelop::Path(defaultCMakeExecutable)).toLocalFile())) | ||
| Show All 11 Lines | 349 | if (projectCMakeExecutable != defaultCMakeExecutable) { | |||
| 353 | } | 353 | } | ||
| 354 | } | 354 | } | ||
| 355 | return KDevelop::Path(projectCMakeExecutable); | 355 | return KDevelop::Path(projectCMakeExecutable); | ||
| 356 | } | 356 | } | ||
| 357 | return KDevelop::Path(defaultCMakeExecutable); | 357 | return KDevelop::Path(defaultCMakeExecutable); | ||
| 358 | } | 358 | } | ||
| 359 | 359 | | |||
| 360 | KDevelop::Path currentInstallDir( KDevelop::IProject* project, int builddir ) | 360 | KDevelop::Path currentInstallDir( KDevelop::IProject* project, int builddir ) | ||
| 361 | { | 361 | { | ||
| 362 | const QString defaultInstallDir = | 362 | return KDevelop::Path(readBuildDirParameter( project, Config::Specific::cmakeInstallDirKey, QString(), builddir )); | ||
This does not make sense. The default install prefix *is* /usr/local. https://cmake.org/cmake/help/v3.0/variable/CMAKE_INSTALL_PREFIX.html kfunk: This does not make sense. The default install prefix *is* /usr/local.
https://cmake. | |||||
I presume the idea is that if KDevelop itself has been built locally and installed to some non-standard path, the user will want to use the same path to install their other projects. This seems a bad idea to me; it's only helpful in very specific circumstances and will be very confusing if the behaviour isn't desired. flherne: I presume the idea is that if KDevelop itself has been built locally and installed to some non… | |||||
On further thought -- won't this cause all distro-built versions to try to install projects under /usr rather than /usr/local? That would *really* be a bad idea. flherne: On further thought -- won't this cause all distro-built versions to try to install projects… | |||||
Indeed, this is for when you maintain a software install in a parallel prefix, whether that be through the aforementioned projects like Gentoo Prefix or MacPorts, or manually. There also used to be a Project Neon5 which had the same approach. The change doesn't change the default, but why would using '/usr' (instead of '/usr/local') be worse than using 'c:\Program Files' under MS Windows? Or maybe the default install dir should simply be empty in order not to assume anything over whatever default the local cmake installation is set to? rjvbb: Indeed, this is for when you maintain a software install in a parallel prefix, whether that be… | |||||
Nope, it still does not make sense. defaultInstallDir here is resembling CMake's default install prefix, which is not dependent on KDevelop's install prefix. Why would it...
Nope. It *does* change the default if KDevelop's install prefix is not /usr/local. The second point is moot. It's what CMake chose as default for these platforms.
So we're back on applying hacks/work-arounds on half-baked solutions? kfunk: Nope, it still does not make sense. `defaultInstallDir` here is resembling CMake's default… | |||||
| 363 | #ifdef Q_OS_WIN | | |||
| 364 | QStringLiteral("C:\\Program Files"); | | |||
| 365 | #else | | |||
| 366 | QStringLiteral("/usr/local"); | | |||
| 367 | #endif | | |||
| 368 | return KDevelop::Path(readBuildDirParameter( project, Config::Specific::cmakeInstallDirKey, defaultInstallDir, builddir )); | | |||
| 369 | } | 363 | } | ||
| 370 | 364 | | |||
| 371 | QString projectRootRelative( KDevelop::IProject* project ) | 365 | QString projectRootRelative( KDevelop::IProject* project ) | ||
| 372 | { | 366 | { | ||
| 373 | return baseGroup(project).readEntry( Config::Old::projectRootRelativeKey, "." ); | 367 | return baseGroup(project).readEntry( Config::Old::projectRootRelativeKey, "." ); | ||
| 374 | } | 368 | } | ||
| 375 | 369 | | |||
| 376 | bool hasProjectRootRelative(KDevelop::IProject* project) | 370 | bool hasProjectRootRelative(KDevelop::IProject* project) | ||
| ▲ Show 20 Lines • Show All 352 Lines • Show Last 20 Lines | |||||
This is also cumbersome, it would make sense in case CMake is shipped (or bundled with) KDevelop, but it isn't.