QSP patch/activator (Review Request 126125: [OS X] make KDE's trash use the OS X trash)

[René J. V. Bertin]

Alex Merry wrote:


> I'd be fine with adding something to KDECompilerSettings as long you had
> to explicitly ask for it to be enabled when running CMake. But if you're
> doing that, why not set CMAKE_EXE_LINKER_FLAGS_INIT directly on the
> CMake command line, or use the LDFLAGS env var? I assume this could all
> be done as part of the macports build process fairly easily, and that
> would seem to make most sense, given this is a macports-centric thing.

If I'm right it's not just going to be a MacPorts-centric thing, but something 
that all comparable projects (that aim to provide dependencies that are shared 
among dependents) are likely to adopt.

Indeed, MacPorts' build system is very flexible (Tcl scripts, basically); I'm 
more concerned about what currently goes on in CMake. Right now the activator is 
added in 2 distinct steps:
- tell CMake to find the corresponding Qt component, either in the composite 
call that finds multiple components, or using separate find expressions
- add the module as a link_target_library (PRIVATE Qt5::QspXDG).

That 2-stage nature probably makes it difficult to add the activator via the 
command line though I'm guessing that I might be able to get away with 
specifying "-framework QspXDG" on the commandline (and lose configure-time 
checking if the component exists).
BTW, not that it's already being used, but is CMAKE_EXE_LINKER_FLAGS_INIT 
incremental or does one have to accumulate all elements first and use a single -
DCMAKE_EXE_LINKER_FLAGS_INIT=XX argument?

R.