New makefile to fix dependency errors

[Meiye-lj]

Hi,

Based on our study, we found some dependency errors. We have tried to fix them.

[chrchr-github]

Seems like dmake.cpp needs to be adapted.

[danmar]

in my humble opinion this is wrong. the checkinternal.cpp includes various headers. The CHECK_INTERNAL is sometimes defined.

[firewave]

Looks like it was not compiled with CHECK_INTERNAL defined.

[danmar]

The externals/tinyxml2/tinyxml2.h is already a dependency.

[firewave]

Based on our study, we found some dependency errors. We have tried to fix them.

Thanks for your contribution. Please provide more details on how you determined this and what issues this might fix.

FYI the Makefile is quite basic and lacks lots of features. You should use CMake if possible as it is way more complete (although it is still missing a few things from make).

[Meiye-lj]

Based on our study, we found some dependency errors. We have tried to fix them.

Thanks for your contribution. Please provide more details on how you determined this and what issues this might fix.

FYI the Makefile is quite basic and lacks lots of features. You should use CMake if possible as it is way more complete (although it is still missing a few things from make).

We recently conducted a study to detect build dependency errors, focusing on missing and redundant dependencies.
*Missing dependencies (MDs), are dependencies that are not declared in the build script but will be used in the full build.
MDs prevent GNU Make from recompiling programs after they have been modified and regenerating all the targets that contain them, resulting in incorrect incremental builds
*Redundant dependencies (RDs), are dependencies that are declared in the build script but will not be used in the full build.
RDs refer to static build dependencies which declare dependencies that are not the actual build dependencies of the target. RDs cause the build system to perform unnecessary incremental builds. In addition, RDs cause targets that could be executed in parallel to be executed sequentially, reducing the build efficiency.
We analyze the actual software construction process and detect dependency errors. We found some dependencies missing （i.e. externals/tinyxml2/tinyxml2.h in /checkuninitvar.o） some dependencies redundant (i.e. dependencies in checkinternal.o).

[firewave]

If this include was required the code would not build as there is no .h files which includes tinyxml2.h so each .cpp files which needs that information needs to include this.

In the code in question the include is not necessary as the type is forward declared and it used as pointer-only.

[danmar]

👍 @Meiye-lj please handle forward declarations in your tool because it's an important way to reduce dependencies.

[firewave]

This also appears to be unnecessary. simplecpp.h is only included by preprocessor.h which is not includes by any other .h file. It is used pointer-only so forward declaration will suffice.

[firewave]

This also appears to be unnecessary. simplecpp.h is only included by preprocessor.h which is not includes by any other .h file. It is used pointer-only so forward declaration will suffice.

[firewave]

We are using our own tool dmake which generates the dependencies based on the analysis of the includes used in the code which utilizes the code our analysis is using.

We are also include-what-you-use to make sure that we are not including unnecessary includes and are also not relying on transitive includes. As of #5540 our code should be finally clean except and we only experience a few false positives - it is possible there are still some false negatives but those should be few and those should not be related to user includes but system ones.

Based on your findings it seems there might have been some shortcomings in your study which need to be addressed.

[danmar]

We are also include-what-you-use to make sure

However that only checks the source code. It does not check the Makefile dependencies as far as I know.

@Meiye-lj
I think your tool which seems to check Makefile dependencies IS interesting. But it seems more development is needed. Please share with us when it works properly. If it works well I would be happy to spread the word.. it could be a valuable complement to Cppcheck..

[danmar]

I close this for now. Feel free to reopen if results has been fixed.

[Meiye-lj]

Thank you! Our work is not yet public. When it becomes public. I'd be happy to share it. We re-detected cppcheck based on its most recent commits, and we found that since commit ID afe05d0, cppcheck no longer has missing dependencies. For earlier versions, it looks like our detection of missing dependencies is not false positives. I'd be happy to share our test reports if you're interested. ----- 原始邮件 ----- 发件人：Daniel Marjamäki ***@***.***> 收件人：danmar/cppcheck ***@***.***> 抄送人：Meiye-lj ***@***.***>, Mention ***@***.***> 主题：Re: [danmar/cppcheck] New makefile to fix dependency errors (PR #5546) 日期：2023年10月13日 18点38分 We are also include-what-you-use to make sure However that only checks the source code. It does not check the Makefile dependencies as far as I know. @Meiye-lj I think your tool which seems to check Makefile dependencies IS interesting. But it seems more development is needed. Please share with us when it works properly. If it works well I would be happy to spread the word.. it could be a valuable complement to Cppcheck.. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

[firewave]

Sorry for the late reply.

You should not be using hard-coded dependencies in a Makefile at all. You should generate the dependencies based on the source. This functionality is integrated with the GNU compilers GCC and Clang via the -MM option which utilizes their preprocessor. The result looks like this:

$ gcc -MM input.cpp
input.o: input.cpp input.h
$ clang -MM input.cpp
input.o: input.cpp input.h

An example on how to integrate it into your Makefile can be found here: https://stackoverflow.com/a/313787/532627. That would be a proper future-proof fix instead of just adjusting the hard-coded ones.

Modern build systems like meson or CMake have this integrated so you don't have to take care of it by yourself anymore (not sure about Autoconf). So there is actually no external tooling necessary to do this.

dmake is basically duplicating this functionality but it is a good case of dogfooding and making sure that our preprocessor is working correctly. It does additional things though like updating the source file lists in other project files we maintain so there is no need to update those manually when we add new files.

Our Makefile is also not leveraging built-in make rules which leads to unnecessary code which is not actually necessary.