Suppress warnings in third-party code

[DomClark]

This should improve compatibility with newer compiler versions, and allow us to turn up the warning level for our own code. I have made no attempt to fix any existing warnings in this PR, and haven't removed any warning suppression flags, except those that applied only to third-party code or were duplicated.

The main technique here is to ensure all third-party code is built in separate targets from first-party code, and to set the SYSTEM property on those targets. This property will cause include directories associated with these targets to be passed to the compiler as system include directories, suppressing warnings in the headers they contain (automatically in the case of GCC and Clang, and with the addition of /external:W0 in the case of MSVC). To suppress warnings when building third-party source files, we check the SYSTEM property with a generator expression, which determines which set of warning flags to pass.

The biggest difficulty in separating third-party code into its own targets was getting everything to link properly afterwards; this is the source of most of the complexity in this PR. Object libraries cannot be linked transitively (only the usage requirements propagate, not the objects themselves), whereas static libraries publicly targeted by a shared library will also be included when linking dependents of that shared library (which is undesirable when the shared library is meant to export the symbols from the static library). To address this, I have written a helper module to support a new static linking scope. CMake has two scopes when setting attributes on a target: the private scope applies only to the target in question, whereas the interface scope applies to all of the target's transitive dependents, at least until it reaches a private scope (the public scope is simply both of these scopes together). The static scope applies only to statically-linked transitive dependents, i.e. those within the same dynamic library or executable - it will not extend to dependents that link dynamically to the target in question.

The core now needs some compile definitions from libraries it depends on. We used to have the lmms target depend on all the libraries required by the core, and manually copy the include directories over to lmmsobjs. Rather than extend this to copy compile definitions too, I have taken advantage of the newer CMake version available to us and had lmmsobjs itself depend on those libraries, with lmms inheriting the requirements through a public dependency on lmmsobjs.

I have considered the CAPS plugin suite to be third-party, despite it being vendored into our source tree. There is an effort to submodule it in #4027, and we don't maintain the vendored copy much anyway.

I have removed the external weakjack library that was installed into plugins/optional (but not the copy built into the core), as I believe it exists by mistake. It was added to stable-1.2 in #3958, and to master in #3970. It was then removed from stable-1.2 in #4186, but not removed from master, even when merging from stable-1.2. The comment at #4094 (comment) suggests that it is no longer required, and there are no references to it left that I can find.

[FyiurAmron]

LGTM; I don't have the time needed to test it ATM, but the idea looks very good (and is basically solving a blocker for me :), so my personal opinion on this is "merge ASAP" :D

[FyiurAmron]

@DomClark BTW, do we have some code/workflow guidelines for LMMS repo? I guess so, but I couldn't find them. I'm asking wr.t. the commit naming for PRs - also, are we squashing/rebasing? AFAIR, the commits from my PRs were merged verbatim, so that would raise the question whether e.g. a squash/rebase would be needed here, to get rid of the "attempt"/"try" etc. WIP commits?

[Rossmaxx]

Dw about it, we'll squash it finally

[FyiurAmron]

@Rossmaxx out of curiosity, doesn't it stay in the squashed commit message though as bullet points?

[Rossmaxx]

No one looks at the bullet points, or the person who merges might delete the cleanup points from the message.

[FyiurAmron]

@Rossmaxx

No one looks at the bullet points

be wary of using the existential or universal quantifier :D

[FyiurAmron]

@DomClark I've rebased on your branch and updated the relevant stuff, but on GCC 13 https://github.com/LMMS/lmms/actions/runs/9529541161/job/26268401821?pr=7283#step:9:2777 is still there (it happens entirely in include/libgig/DLS.h if I'm reading it correctly). Either I'm missing something obvious, or it also needs to have the SYSTEM treatment.

[FyiurAmron]

/plugins/GigPlayer/CMakeLists.txt should probably also be updated to leverage SYSTEM

[DomClark]

/plugins/GigPlayer/CMakeLists.txt should probably also be updated to leverage SYSTEM

That's a good point. I'd only made changes relating to the third-party code that we submodule, assuming that system-provided headers would already be considered as such. While this is true for some libraries that we consume as imported targets (imported targets are implicitly flagged as SYSTEM), there are plenty of libraries for which we manually call include_directories. The ideal long-term approach for these is to wrap them in imported targets too (in fact, this is done for libgig in #7162), but that's out of scope for this PR. For now, I've added SYSTEM to all include_directories and target_include_directories commands that add system include directories to first-party targets.

[DomClark]

BTW, do we have some code/workflow guidelines for LMMS repo? I guess so, but I couldn't find them. I'm asking wr.t. the commit naming for PRs - also, are we squashing/rebasing? AFAIR, the commits from my PRs were merged verbatim, so that would raise the question whether e.g. a squash/rebase would be needed here, to get rid of the "attempt"/"try" etc. WIP commits?

As Rossmaxx says, we generally use GitHub's "squash and merge" feature, but there are occasional cases when we don't. I tend to remove the bullet points that GitHub automatically puts into the commit message box, unless they happen to add useful information (which is rarely the case). However, we don't have an official procedure, and some people leave the default message unedited. As an exception, co-author lines we always leave untouched, to make sure people remain credited or blamed properly.

As for commit/PR naming, we tend to use what is industry-standard, i.e. a short title in the imperative mood. This is even less enforceable than the merge procedure, of course, as anyone can open a pull request. I usually avoid editing PR titles, so as not to appear rude to people who may not speak English fluently, but I'd be lying if I said I weren't ever so slightly bothered by titles such as "adds feature" or "added feature" instead of "add feature". When merging a pull request, GitHub automatically adds its number in brackets to the end of the commit message (although this can be edited), so it's worth trying to make PR titles extra short, as they will be longer once merged. Other peeves of mine are things like "(rework)" at the end of PR titles - this is meaningless in commit history, as the original PR won't have been merged - and issue numbers, which can be confusing when the PR number is added too at merge time. Additionally, an issue number is not a substitute for a description of what was fixed, as it is meaningless outside of GitHub.

In short, there are no hard-and-fast rules, but think about what the message will look like when merged, and whether it will be meaningful to someone who is looking at the commit locally, rather than on GitHub. If you ever want a particular description to be included when a PR is merged, feel free to say.

[FyiurAmron]

tested on #7283 and works like a charm with GCC 13 _{(don't mind the MinGW 32-bit failing, it's completely unrelated to this one)} - can't wait to see it merged!

[Veratil]

Checking the configure output... Not sure if we want to handle any of these here or not.

We have quite a few of these:

CMake Warning (dev) at /usr/share/cmake-3.29/Modules/FindPackageHandleStandardArgs.cmake:438 (message):
  The package name passed to `find_package_handle_standard_args` (SOUNDIO)
  does not match the name of the calling package (SoundIo).  This can lead to
  problems in calling code that expects `find_package` result variables
  (e.g., `_FOUND`) to follow a certain pattern.
Call Stack (most recent call first):
  cmake/modules/FindSoundIo.cmake:14 (find_package_handle_standard_args)
  CMakeLists.txt:409 (FIND_PACKAGE)
This warning is for project developers.  Use -Wno-dev to suppress it.

I think this is new:

CMake Deprecation Warning at src/3rdparty/qt5-x11embed/CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.

Build output had this show up now:

-- The CXX compiler identification is GNU 9.4.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done (0.2s)
-- Generating done (0.0s)
CMake Warning:
  Manually-specified variables were not used by the project:

    CMAKE_C_FLAGS

[Veratil]

LGTM, easy to confirm changes work with CI since this is build system

[DomClark]

Checking the configure output... Not sure if we want to handle any of these here or not.

See #7322 for the CMake warnings. This PR is intended to address C/C++ warnings.