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

Kevin Funk noreply at phabricator.kde.org
Fri Nov 30 14:20:51 GMT 2018


kfunk added inline comments.

INLINE COMMENTS

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

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.

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

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...

> 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?

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.

> That said, filtering out '/usr' won't be hard.

So we're back on applying hacks/work-arounds on half-baked solutions?

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/4d53bece/attachment-0001.html>


More information about the KDevelop-devel mailing list