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.

That's also what I meant.

That said, the install location field is always empty in the cmake import wizard when I create a new project. Which is probably fine because why would KDevelop bother hardcoding a default cmake setting esp. if that setting is dubious (argue as you might, c:\Program Files *is* the equivalent of /usr and I gather from Francis' comment that /usr would not have been used here if that had been CMake's choice on Unix).

But maybe a proper cmake option to configure the default would raise less eyebrows?
If there is an issue with setting the default to /usr then /usr/local should be equally off-limits on systems where that tree is under distribution control (like FreeBSD).

I've tested the idea of NOT specifying an install prefix default when none has been configured. To the best I can see this does not lead to invalid cmake invocations (aka -DCMAKE_INSTALL_PREFIX=). Instead, this does exactly what you'd expect: cmake will use whatever is its default for the current platform. The result will be obtained from the CMakeCache later on.
In other words, there doesn't appear to be any reason to hardcode assumptions about CMake's defaults, and not doing that should be a suitable compromise for everyone. It also removes the need for conditional code.

@apol Do you think that makes sense?

Just some general remarks: Storing the application's install prefix inside the binary itself almost always smells like bad design. Thus the concerns here. You rather want to do this dependent on the kdevelop binary's application path (cf. http://doc.qt.io/qt-5/qcoreapplication.html#applicationDirPath)

Easily explained with: On Windows this will just fail (as the install prefix can be anything, as the *user* chooses where KDevelop will end up during installation).

On Linux quite possibly too, I think many packaging systems install into some temporary dir and then copy the deployment out of there for archiving.

On Linux quite possibly too, I think many packaging systems install into some temporary dir and then copy the deployment out of there for archiving.

That uses make install DESTDIR=/path/to/distdir; MacPorts does the same. All this does is prepending DESTDIR to PREFIX.
Using the install prefix during the build process isn't that uncommon with autoconf projects, and it is in basically what happens when you build using full rpaths.

The question is moot if the manpage plugin stops referring to hardcoded paths. But is that plugin even of much use on MS Windows?

If the problem this patch solves is to have CMAKE_INSTALL_PREFIX to be set for newly-created projects, why not just add a configuration option to the CMake plugin?

No, it went beyond that: the original underlying principle was "don't assume or hardcode /usr/local anywhere, use whatever install prefix the user specified".

The default location for new projects used by the cmake plugin is a bit in a category of its own as evident from early feedback on my patch, which is why I now propose NOT to set any default in the code.

Adding cmake option for this could be of interest but I think it would be even better to add a (toplevel or session-specific) configuration option so the user can indicate where new projects should be installed. That could go right into the Settings/Projects pane, under the "Projects base directory" setting.
Would be a different diff though.