Makefile: need to do a target before including another makefile

Part of my Makefile:

CPUDEPS=./mydeps.cpu
(...)
deps: $(CPUDEPS)

$(CPUDEPS): $(CCFILES)
 @echo [DEPS] CPU
 $(CMDECHO)makedepend -Y -s'# CPU sources dependencies generated with "make deps"' \
  -w4096 -f- -- $(CFLAGS) -- $^ 2> /dev/null > $(CPUDEPS)
(...)
sinclude $(CPUDEPS)

Problem 1: includes are done during the first phase of processing, targets during the second phase; so, if ./mydeps.cpu doesn't exist and I "make deps", I get first the error

Makefile:335: ./mydeps.cpu: No such file or directory

I hide the error using sinclude instead of include, but the problem is still there: the old file is included, not the just-generated-one. Have to run it twice to include the updated file. This is because make does a two-phase processing; is there any way to tell make to complete the target deps before parsing the includes?

Problem 2: even if the file ./mydeps.cpu doesn't exist and make dep开发者_StackOverflow社区s actually creates it, I always get a "make: Nothing to do for deps". This doesn't happen with other targets. I don't understand why and how to avoid it.

Problem 1 is non-existant: before building a target, make automatically rebuilds makefiles (with implicit rules if no explicit rule is provided). So having a rule for the makefile ensures that will always be up to date, there is no need to run deps twice. Additionally, since CPUDEPS is a makefile, it will be updated automatically before any other rule is run, so dependencies will always be updated if necessary and make deps is not needed. You can probably notice this by yourself by observing the [DEPS] line being echoed if any of the CCFILES becomes more recent that the dependency file.

For Problem 2, adding anything to the recipe ensures that make doesn't complain about having nothing to do. If there is nothing else, you can use something like @echo OK to give feedback to the user, or a simple @true if you prefer totally silent makes.

What you are trying to achieve is useless: you can use the dependencies file that was created during the previous build. That's enough.

The main reasoning behind that rule is:

• if you haven't changed any of your files, then the dependencies file is up-to-date, and there's nothing to build.
• if you have changed anything, even very deep into your #include chain, on an existing file that were used by previous build, then the dependencies file have already caught it. You'll rebuild what is needed.
• if you change something in a new file (you add that file!) then it was not used by previous build, and not listed in dependencies. But if you really want to use it, then you have to modify at least one of your other files that was used before, and you're back on the previous case.

The solution is to create the dependencies file during the normal process of the compilation, and to optionally include it (with sinclude) if it is present.