Dont use boost when its disabled USE_BOOST=Off

[pfultz2]

We are not using boost correctly as it fails when its not installed in the system path. We should be able to disable it when setting it to Off.

[firewave]

How does this happen? What is the error?

[pfultz2]

This is the error:

cppcheck/lib/smallvector.h:27:10: fatal error: 'boost/container/small_vector.hpp' file not found
   27 | #include <boost/container/small_vector.hpp>
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This happens when building testastutils.cpp when it includes astutils.h. Making the include PUBLIC doesnt fix the issue because the testrunner doesnt link cppcheck-core unless BUILD_CORE_DLL is set(which doesnt work on linux or mac).

This cmake is such a mess and overcomplicated. It should use the BUILD_SHARED_LIBS variable to automatically make libraries as shared or static, and remove BUILD_CORE_DLL. There is no reason to use object libraries. And all the usage requirements should be properly set for cppcheck-core instead of repeating it for the tests.

Either way, even if we fix this, we should still be able to disable boost even if its installed on the system which is what this will allow.

[firewave]

There should be not shared libraries at all. It only exists on Windows (it is not supposed to be working on other platforms) and I reckon it might have been an oversight in the Visual Studio project when that was introduced. I only added it to CMake so it will produce the same output as the included Visual Studio project (which should also not exist).

I enabled Boost unconditionally because it improves performance measurably. I am still puzzled how CMake adds the Boost defines if it didn't find the library.

[pfultz2]

There should be not shared libraries at all.

The default would be static, but for development, shared library is convenient as building everything will be faster. If the cmake was setup properly this would be trivial to support. Removing these object libraries would make the cmake way simpler.

I enabled Boost unconditionally

Then set USE_BOOST to On by default. Still, there should be a way to disable it by setting it to Off.

because it improves performance measurably.

The perf probably doesnt help much when using the Debug build with UBSAN.

I am still puzzled how CMake adds the Boost defines if it didn't find the library.

CMake finds boost and adds the include path to cppcheck-core, but since we include boost in the header files and we cant propagate usage requirements(because we are using object libraries) then anything that uses cppcheck-core will break.

I dont really have time to refactor all the cmake, so for now being able to disable it and run the tests is good short-term solution.

[firewave]

CMake finds boost and adds the include path to cppcheck-core, but since we include boost in the header files and we cant propagate usage requirements(because we are using object libraries) then anything that uses cppcheck-core will break.

It is weird I have not experienced any issues with it. And I have countless different configurations and compilers locally...

It is currently completely broken when using Visual Studio because CMake removed the old module but only when it is in PATH which requires special parameters on Windows by the user and I reckon nobody knows how to do that.

I dont really have time to refactor all the cmake, so for now being able to disable it and run the tests is good short-term solution.

There is not much to refactor. As mentioned before the shared library should have never been added to CMake.

USE_BOOST=On is to enforce the usage - so it is supposed to fail if it doesn't find it. The default is to use it if it is found. Being able to completely disable it makes sense though - I did not consider that.

[firewave]

It is weird I have not experienced any issues with it. And I have countless different configurations and compilers locally...

I understand what is going on now and it has nothing to do with shared/static/object libraries.

-- USE_BOOST =             OFF
-- Boost_FOUND =           1
-- Boost_VERSION_STRING =  1.83.0
-- Boost_INCLUDE_DIRS =    /usr/include
-- USE_BOOST_INT128 =      OFF

The boost include folder is located in a folder which is always available to the compiler. testrunner is lacking that include folder (which simply adding would be a "proper" fix going by our current approach) so if it is placed in a different location it cannot find it. So I should be able to reproduce that on Windows (after I "fixed" it actually taking the Boost includes - see #7541).

[pfultz2]

As mentioned before the shared library should have never been added to CMake.

If its setup properly then shared libraries dont need to be added, it should be supported out of the box. Shared libraries are useful to have for development.

I understand what is going on now and it has nothing to do with shared/static/object libraries.

It is related. Setting the include path to public on the cppcheck-core doesnt fix the issue, since the testrunner doesnt link cppcheck-core because its an object library. If we built this as a normal library(not object library) then the testrunner would link cppcheck-core and the public include paths would be added.

USE_BOOST=On is to enforce the usage - so it is supposed to fail if it doesn't find it. The default is to use it if it is found.

But you could set it to On if is found, and if the user sets it to On throw an error if its not found.

The boost include folder is located in a folder which is always available to the compiler. testrunner is lacking that include folder (which simply adding would be a "proper" fix going by our current approach) so if it is placed in a different location it cannot find it. So I should be able to reproduce that on Windows (after I "fixed" it actually taking the Boost includes - see #7541).

Sure, in the meantime you can merge this since it will fix the issue, and you can work out the changes on windows.

[firewave]

Sure, in the meantime you can merge this since it will fix the issue, and you can work out the changes on windows.

It "fixes" the issue but the change is wrong.

It is related. Setting the include path to public on the cppcheck-core doesnt fix the issue, since the testrunner doesnt link cppcheck-core because its an object library. If we built this as a normal library(not object library) then the testrunner would link cppcheck-core and the public include paths would be added.

Yes - you can put everything upside down just because a single option was missing. It was a simple oversight which was made a few years ago and was exposed because we actually enabled the code. As usual in this code base ...

[firewave]

I posted #7660 which also adds CI jobs which detect the issue.

[firewave]

I filed https://trac.cppcheck.net/ticket/14003 about being able to disable boost again.

[pfultz2]

Yes - you can put everything upside down just because a single option was missing. It was a simple oversight which was made a few years ago and was exposed because we actually enabled the code. As usual in this code base ...

More like putting it right side up. #7658 fixes any future issues we might have. If another component that uses the core(like the gui or cli) happens to include a file that includes boost, it will still work correctly. Plus it will make it easier to add dependencies or new executables.