CMake cleanup #7658

pfultz2 · 2025-07-09T16:58:42Z

This removes the object libraries and uses normal cmake targets. This helps simplifies a lot of the cmake since we can properly propagate usage requirements.

pfultz2 · 2025-07-09T18:30:14Z

Because of the global registration an object library will need to be used for at least cppcheck-core, but we can still wrap it in an interface library so it can propagate usage requirements though.

firewave · 2025-07-09T19:17:25Z

Using interface libraries would be an acceptable modernization (although I personally detest them - I had to many problems with them in the past). We need to test though that things work with the currently specified minimum CMake version and raise it appropriately if necessary.

But if we actually want to support shared libraries there is a lot of work to be done:

visibility handling on non-Windows platforms
needs to add annotation to all exported symbols (currently it was only set for the ones actually used in tests)
needs ABI handling/versioning for the shared objects
adjust the install targets
adjust the shipped Visual Studio project to generate the same output files
adjust the Windows installer
CI jobs to test this on all platforms
... possibly even more things I cannot think off the top of my head

And IMO externals should not be shared libraries.

Also we still have static objects in our code which possibly makes the proper usage of the shared objects impossible. Beside that I reckon there never was and never will be a single user of the shared objects. And the current implementation was only partial.

We should not be supporting shared libraries at all because it just causes more work now and in the future and I do not see any upsides at all. We should be removing features instead of adding and simplifying things instead of making them even more complex (with latter I am referring to the support matrix - not the code).

pfultz2 · 2025-07-09T20:14:39Z

The purpose of the shared libraries would only be for local dev. I wouldn't envision us installing them.

firewave · 2025-07-09T20:27:49Z

The purpose of the shared libraries would only be for local dev.

Please elaborate. I do not see how it would be of any use - especially given that it was never available and nobody complained. And if we want to support that we need to test it i.e. CI workflows. Otherwise it is just more stuff which rots away in this repo.

I wouldn't envision us installing them.

It would be possible but it would not work - so it should not be allowed.

pfultz2 · 2025-07-09T22:07:06Z

So with this change there is new -Wsuggest-attribute=noreturn warnings. I am not sure why we didnt warn before. I dont see us disabling warnings. Do you know why?

pfultz2 · 2025-07-09T22:08:59Z

Please elaborate. I do not see how it would be of any use

Faster linking time.

firewave · 2025-07-10T09:15:26Z

externals/tinyxml2/CMakeLists.txt

-target_include_directories(tinyxml2 SYSTEM PUBLIC .)
+target_include_directories(tinyxml2 PUBLIC .)


That flag needs to depend on the EXTERNALS_AS_SYSTEM option.

firewave · 2025-07-10T09:15:43Z

lib/CMakeLists.txt

+# if (NOT CMAKE_DISABLE_PRECOMPILE_HEADERS)
+#     target_precompile_headers(cppcheck-core-private PRIVATE precompiled.h)
+# endif()


Needs to be enabled again before merging.

Yea, that was to test the CI. I was getting error:

../../../lib/CMakeFiles/cppcheck-core-private.dir/cmake_pch.hxx.gch: file not recognized: file format not recognized

Now with it disabled I get an error that there isnt a make rule for it.

I see, you are explicitly building it in selfcheck, but its using the wrong target name.

Switching to the OBJECT library directly fixed this issue.

firewave · 2025-07-10T09:20:33Z

externals/tinyxml2/CMakeLists.txt

-if (BUILD_CORE_DLL)
-    target_compile_definitions(tinyxml2_objs PRIVATE TINYXML2_EXPORT)
-endif()
+add_library(tinyxml2 ${srcs} ${hdrs})


This should be able to become a shared library.

firewave · 2025-07-10T09:20:40Z

externals/simplecpp/CMakeLists.txt

-if (BUILD_CORE_DLL)
-    target_compile_definitions(simplecpp_objs PRIVATE SIMPLECPP_EXPORT)
-endif()
+add_library(simplecpp ${srcs} ${hdrs})


This should be able to become a shared library.

It will if we set BUILD_SHARED_LIBS.

firewave · 2025-07-10T09:24:04Z

frontend/CMakeLists.txt

If this can become a shared library (which it shouldn't) it also needs the import/export handling. This is getting way more complicating than the existing code.

If this can become a shared library (which it shouldn't) it also needs the import/export handling.

Only on windows is that needed. Either way the purpose of this PR is not to support shared libraries.

Unrelated to this comment, this library shouldn't be an object library. I am not sure why its working.

I see why this works. Since cmake 3.12, object libraries can be linked directly instead of adding the $<TARGET_OBJECTS> to the sources. This will make it simpler.

firewave · 2025-07-10T09:25:54Z

Faster linking time.

Yes, that probably will save a few microseconds...

Unlike the precompiled headers you just disabled which will actually save a lot of compilation time...

So with this change there is new -Wsuggest-attribute=noreturn warnings. I am not sure why we didnt warn before. I dont see us disabling warnings. Do you know why?

How do these occur? I did not see them in the CI failures.

firewave · 2025-07-10T09:55:27Z

cli/cppcheckexecutor.cpp

-    const int res = pclose(p);
+    int res = pclose(p);


Fixes (among others) in macos-15 builds:

/Users/runner/work/cppcheck/cppcheck/cli/cppcheckexecutor.cpp:746:9: warning: cast from 'const int *' to 'int *' drops const qualifier [-Wcast-qual] 746 | if (WIFEXITED(res)) { | ^ /Applications/Xcode_16.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX15.0.sdk/usr/include/sys/wait.h:152:26: note: expanded from macro 'WIFEXITED' 152 | #define WIFEXITED(x) (_WSTATUS(x) == 0) | ^

Failing builds on warnings is tracked via https://trac.cppcheck.net/ticket/12021.

Its needed to fix CI, because they became errors in the CI with these changes. I am not sure why it didnt error out before in the CI.

The scope is getting way too big with a lot of questionable sidecar changes. This needs to be fixed more incrementally.

Its needed to fix CI, because they became errors in the CI with these changes. I am not sure why it didnt error out before in the CI.

That should not be happening. That indicates that something is wrong in these CMake change.

pfultz2 · 2025-07-11T00:49:17Z

@firewave Alright, I think this is ready to go. This will fix the issue with using boost(#7655 is still needed if we want to disable boost).

firewave · 2025-07-14T10:29:56Z

@firewave Alright, I think this is ready to go. This will fix the issue with using boost(#7655 is still needed if we want to disable boost).

There's several things which do not look right to me. I am not feeling very well right now so it will take quite a while for me to review and even understand what this is doing since the changes are hard to follow.

Also the proper fixes for the boost issues should be merged as since those will have actual tests for the behavior changes.

pfultz2 · 2025-07-14T15:53:28Z

There's several things which do not look right to me. I am not feeling very well right now so it will take quite a while for me to review and even understand what this is doing since the changes are hard to follow.

Hope you feel better soon. Here is a summary/explanation of the changes which hopefully can help you review the PR.

The biggest change is to move all the usage requirements into the target and link with target directly instead of using $<TARGET_OBJECTS> and manually adding it for each consumer. So writing target_link_libraries(someTarget cppcheck-core) it will link with cppcheck-core and add any headers or defines that are need to use cppcheck-core.

So now I removed the manual includes and linking, and just link a single target directly. I did this based on the includes in the cmake, but I didnt check the source code if its actually including headers from the component. In the future, we can probably do some more cleanup up here. I dont think every component that is linking simplecpp is using headers from simplecpp, but I didnt check the c++ source files and added it as it was being included in the cmake.

For tinyxml2, I created a target even when we are using an external tinyxml2. So we just need to link the tinyxml2 and no longer to check if its external and link something else.

The cppcheck-core will still be an object library when BUILD_SHARED_LIBS=Off because of the auto-registration of the checks. I realized later that object libraries can now be linked starting in cmake 3.12, which means object libraries can still propagate usage requirements as well. In the future, we could consider making other libraries OBJECT as well.

Supporting BUILD_SHARED_LIBS=On is beyond the scope of this PR, but I did test this on non-windows and it does work. To support this on windows, will probably just need some small tweaks to support(such as setting WINDOWS_EXPORT_ALL_SYMBOLS property or using an object library), but all these could be addressed in the future if the need arises.

In some places, we were using a couple of source files from another component and rebuilding them again(like filelister.cpp). Instead, I just link the component that builds that source file instead of doing these kind of hacks. If we want to make a subset of source files a seperate component then we could refactor that in the future. I dont do that here since I want to minimize the changes here, but it is something we can address in the future.

As such, the dmake exe needs the cli lib to be built. So we still build the cli lib even when BUILD_CLI=Off, but we wont build a cppcheck executable. I am not sure what the usecase is for BUILD_CLI=Off is, but if its just to build less when using the gui, we can work on improving this in the future in order to minimize the changes here.

pfultz2 · 2025-08-11T22:03:20Z

@firewave Are you able to review this?

sonarqubecloud · 2025-08-11T22:03:38Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

firewave · 2025-08-12T11:48:09Z

@firewave Are you able to review this?

Thanks for the extensive description.

I will take another look at this soon - need to take care of things which piled up in the past few weeks.

The first time I looked at this I saw some different shortcomings in the existing code which need to be singled out/addressed first but I cannot remember what it was.

My aim is to have this resolved in this dev cycle.

pfultz2 added 4 commits July 9, 2025 11:56

CMake cleanup

a72f0e8

Add missing cmake file

7536500

Fix cmake

9524828

Consistent link libraries

aae3fa0

Use object library

e5f8f8c

Use targets

599a54e

pfultz2 added 6 commits July 9, 2025 17:25

Remove const to fix cast

74f853f

Remove noreturn

91afb23

Fix pcre linking

00c462a

Add frontend

0e7f402

Remove SYSTEM

ca5c192

Disable precompile headers for now

be40581

firewave reviewed Jul 10, 2025

View reviewed changes

pfultz2 added 5 commits July 10, 2025 09:42

Remove OBJECT

e690613

Use target_external_include_directories

151d3d0

Update target name

0276fd8

Add verbose flag

25d8719

Remove interface library

f95486d

pfultz2 added 3 commits July 10, 2025 17:45

Make cli available for dmake

5416baa

Fix issues with building with cli disabled

063a2f8

Remove verbose flag

5a27cca

pfultz2 mentioned this pull request Jul 11, 2025

fixed #14002 - added missing Boost include for testrunner #7660

Merged

Remove foreach loop

a4b579d

pfultz2 mentioned this pull request Jul 11, 2025

Dont use boost when its disabled USE_BOOST=Off #7655

Closed

pfultz2 requested a review from firewave July 11, 2025 13:51

firewave added the merge-after-next-release Wait with merging this PR until after the next Release label Jul 14, 2025

Merge branch 'main' into cmake-cleanup

c645209

		target_include_directories(tinyxml2 SYSTEM PUBLIC .)
		target_include_directories(tinyxml2 PUBLIC .)

CMake cleanup #7658

Are you sure you want to change the base?

CMake cleanup #7658

Uh oh!

Conversation

pfultz2 commented Jul 9, 2025

Uh oh!

pfultz2 commented Jul 9, 2025

Uh oh!

firewave commented Jul 9, 2025

Uh oh!

pfultz2 commented Jul 9, 2025

Uh oh!

firewave commented Jul 9, 2025

Uh oh!

pfultz2 commented Jul 9, 2025

Uh oh!

pfultz2 commented Jul 9, 2025

Uh oh!

firewave Jul 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

firewave commented Jul 10, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pfultz2 Jul 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pfultz2 commented Jul 11, 2025

Uh oh!

firewave commented Jul 14, 2025

Uh oh!

pfultz2 commented Jul 14, 2025

Uh oh!

pfultz2 commented Aug 11, 2025

Uh oh!

sonarqubecloud bot commented Aug 11, 2025

Quality Gate passed

Uh oh!

firewave commented Aug 12, 2025

Uh oh!

Uh oh!

firewave Jul 10, 2025 •

edited

Loading

pfultz2 Jul 10, 2025 •

edited

Loading