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. _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
