pnoltes commented on PR #817: URL: https://github.com/apache/celix/pull/817#issuecomment-3858536373
> > Maybe already good to minimise the usage of the gcc static analyzer to a single build? I think, not sure, that there is no benefit to run the gcc static analyzer in the debug build (compared to the RelWithDebInfo build) and seeing the latest build I expect the analyzer performs better with a RelWithDebInfo build. > > +1 > > Moreover, it does not make sense to enable analyzer for tests. Note that half of our code base is for testing code and compilation (and static analysis) of C++ code is very slow. > > WDYT @pnoltes I’m actually in favor of including the test code. While we could create a specific CI pipeline with tests disabled, the goal of enabling the GCC static analyzer is to catch and fix issues as we write new code. Since development happens with tests enabled, the test code should be compatible with the analyzer as well. In my view, we should either accept a slower build (limiting parallelism to (.i.e.) -j4) or postpone the analyzer's introduction. I personally prefer the slower build. We can look into ASF-hosted runners later to optimize. Another option is running the analyzer only on PRs, but I’m not a fan of that approach as it loses immediate feedback during development. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
