D17255: KDevelop: support for installing into a non-standard parallel prefix

[René J.V. Bertin]

rjvbb added inline comments.

INLINE COMMENTS

> kfunk wrote in cmakeutils.cpp:337
> 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.

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.

> flherne wrote in cmakeutils.cpp:370
> 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.

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?
That said, filtering out '/usr' won't be hard.

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?

REPOSITORY
  R32 KDevelop

REVISION DETAIL
  https://phabricator.kde.org/D17255

To: rjvbb, #kdevelop, kfunk
Cc: flherne, kfunk, kdevelop-devel, glebaccon, hase, antismap, iodelay, vbspam, geetamc, Pilzschaf, akshaydeo, surgenight, arrowd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20181130/bf4f11d9/attachment.html>