0

Honestly, I want to control, when is this sub-make rebuilt. To my largest surprise, any time if I use an include generated.sub.Makefile, it also tries to rebuild-it and then re-read my whole Makefile structure.

I do not want it. I know what is in generated.sub.Makefile, and I do not want it to be rebuilt, except if I say so. I do not want it to be rebuilt only because I included it.

The goal is, generated.sub.Makefile should be rebuilt always if I want to, and never if I explicitly did not command it.

Can I somehow do that?

Improve this question
4
  • 2
    That suggests that your generated.sub.Makefile recipe doesn’t allow Make to determine whether it needs to be updated; could you edit your question to show that? Commented May 28 at 21:07
  • @StephenKitt Exactly. The only way I want it to be updated if I say so. I even have a conditional $(error Please run a make something) to handle the case that it does not exist yet. It also gets the solution with it. something became a .PHONY target, creating also generated.sub.Makefile, but there is no more generated.sub.Makefile: target. It can not be built. If make would really complain, then I would create a recipe for him from a single touch command. Commented May 28 at 21:11
  • I'm sure I'm preaching to the choir here and this is for a legacy codebase, but: I found, without fail, that the moment I needed to create Makefiles programmatically, make alone in itself was simply not the right tool. Been there a couple of times – generating figures for TeX documents, preparing data archives for compilation, packaging things for Python, doing different things depending on which version of Boost is installed on a system – and every single time I did things in Makefiles, I ended up discarding my complicated Makefiles and going for a specialized tool for the job. Commented May 29 at 8:47
  • In the case of TeX, that was latexmk, in the case of C++/Boost trouble it was meson or CMake, in Python it was setuptools / poetry, and the same is probably true for anything else: Makefiles have a pretty ad-hoc declarative language, and if you need to create rules on the fly because that language and the tooling isn't good enough, you have just exceeded make's usefulness and should go back to using it as a build tool, not as a configure tool. It's simply not its job nor scope. Plus, the more advanced your usage, the less stable it is. (seriously, every GNU make release breaks smth). Commented May 29 at 8:51

2 Answers 2

Reset to default
2

If you have a rule to make the sub file, then make will check that rule every single time before doing the include (or -include); that's how it works - it wants to ensure everything is up to date.

You may want an "Order Only Prerequisite" which only runs if the file is totally missing.

For example:

include sub.mk sub.mk: | my_other_input_file # do something complicated to make sub.mk with my_other_input_file

This will generate the sub.mk only once and then never again, even if my_other_input_file changes. If you wanted sub.mk to be re-generated, you'd remove it (or add it to your make clean target, etc.)

Improve this answer
-2

What I did:

generated.sub.Makefile:

target was removed. Instead, there is a

.PHONY: make_submake make_submake: things-to-create-generated.sub.Makefile

There is no way to create generated.sub.Makefile by a make command any more.

If make would really complain, I would create a recipe like

generated.sub.Makefile: touch $@

But I think it won't.

Improve this answer
1
  • This answer works only in my case, where the automatic build of the submake is not wanted. Actually, its fine control is wanted - rebuilding exactly if I want, never if I do not, but always if I want it. Idea is that the file is un-buildable by a make command, because it is only a side result of another (PHONY) target. Commented May 28 at 21:19

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.