orangeduck / mpc

A Parser Combinator library for C

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

dependency errors issue

Meiye-lj opened this issue · comments

Hi,

We recently conducted a study to detect build dependency errors, focusing on missing dependencies and redundant dependencies. A missing dependency (MD) is a dependency that is not declared in the build script and a redundant dependency(RD) is a dependency that is declared in the build script that is not actually used. We have detected the following dependency errors in your public projects. Could you please help us to check these dependency errors?

MS
0['/home/lv/WorkSpace/vmake_experiment/mpc-master/build/mpc.o---libmpc.a']

RD
0['build---examples/tree_traversal']
1['build---examples/line_reader']
2['build---examples/smallc']
3['build---examples/foobar']
4['build---examples/maths']
5['build---examples/lispy']
6['build---examples/doge']
7['build---test-file']
8['build---libmpc.so']
9['mpc.c---libmpc.a']
10['mpc.h---libmpc.a']

If MS is a typo for MD, no, mpc.o and libmpc.a are built in this repository itself, not external dependencies.

For the redundant dependencies, these are all also built as a part of building this project. Are you detecting these as being redundant dependencies in some of the targets in the Makefile? If so, which targets have these as redundant dependencies?

Ahh, I see; so you're saying these are dependencies in the Makefile sense (i.e., that some rules depend on files without making that explicit). That's very possible. I'll try to poke around with that in the next few days if I have some free time (both to evaluate and potentially fix).

Okay, now looking into this, I actually don't agree with this analysis.

The dependency on the build directory is (admittedly) a little funny, but it works to ensure that no matter which target you choose to build first, the build directory will be created as-needed. And, having libmpc.a (and libmpc.so) depend on mpc.c and mpc.h, it ensure they'll be rebuilt if you modify either source file. This could also be accomplished by building object-files separately first, but that isn't how it was set up. Finally, also a little funny, libmpc.a actually makes mpc.o unconditionally first. So, having mpc.o as a separate dependency actually would be redundant.

Maybe a good cleanup would be to separate building object files, and then building binaries as a second step (and maybe removing the $(DIST) dependency in favor of making the first line of those rules being $(MKDIR) $(@D)). But, as far as I can tell, there aren't actually any missing or specifically redundant dependencies.

This is true, but as I mentioned, that more or less wouldn't matter (because modifying mpc.c or mpc.h would trigger the rebuild). When would you modify mpc.o but not mpc.c or mpc.h in a real-world example?

Sure, in a makefile where a target doesn't list dependencies (even indirectly), it might lead to the target not being rebuilt appropriately.