Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

remove duplication in Makefile #149

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open

remove duplication in Makefile #149

wants to merge 4 commits into from

Conversation

DerDakon
Copy link
Member

Basically the same what we have already done for catman targets.

Makefile Outdated Show resolved Hide resolved
Makefile Outdated Show resolved Hide resolved
@DerDakon DerDakon requested a review from schmonz June 11, 2020 17:31
Copy link
Member

@schmonz schmonz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works for me with BSD and GNU makes. Nice incremental step in the direction of #52 (and perhaps in the direction of #28).

@josuah
Copy link

josuah commented Jun 14, 2020

I thought the % makefiles rules were not portable because they are not POSIX, but they are at least working on BSD make : https://notqmail.z0.is/patch/0-patch/85555302dd1f6688babb236eb364e9e6f08c96ac/index.make.out

Copy link

@josuah josuah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With these changes, along with multiple others, it looks like we are going more toward hand-maintained Makefile.

As the total number of files decrease (by using libc more), it might become more and more feasible to do so.

Is that the direction we are taking?

@schmonz
Copy link
Member

schmonz commented Jun 14, 2020

My interpretation was the opposite. Interesting. I was thinking anything that highlights patterns in our existing dependencies is a step toward automation. But I’m not actually using redo, and you are. Does this change feel counterproductive to you, or not obviously worth the cost, or something like that?

@DerDakon
Copy link
Member Author

DerDakon commented Nov 9, 2020

Could someone please test if this actually honors both rules? I had the impression that BSD make was only looking at the compile-rule, but ignoring the later dependency rules.

Copy link

@josuah josuah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that this removes dependency on headers: if they get modified and the project is recompiled, the associated .o might not be recompiled. Did nowaday NVMe disks made make clean all cheap enough?

This also introduces % rules that are not POSIX, but there are already common extensions used.

@@ -21,6 +21,9 @@ default: it
.8.0:
$(NROFF) -man $< >$@

%.o: %.c compile
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A slightly less readable but more portable way would be .c.o:, but I doubt this would support adding compile as dependency of .o.

@DerDakon
Copy link
Member Author

Note that this removes dependency on headers: if they get modified and the project is recompiled, the associated .o might not be recompiled. Did nowaday NVMe disks made make clean all cheap enough?

This was basically my question. This is not intended, and it works with GNU make, but if BSD make doesn't support this I can scrap half of it because that is a regression.

@josuah
Copy link

josuah commented Nov 25, 2020

https://notqmail.z0.is/commit/03b8497487b7ebc0580d92059ae77171fff71601/patch/0/log

Works without trouble on that instance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants