bug#77897: "make clean" should do a "rm -rf .deps"

This is a MIME GnuPG-signed message.  If you see this text, it means that
your E-mail or Usenet software does not support MIME signed messages.
The Internet standard for MIME PGP messages, RFC 2015, was published in 1996.
To open this message correctly you will need to install E-mail or Usenet
software that supports modern Internet standards.

--=_ripper.email-scan.com-3232-1745032612-0001
Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Peter Johansson writes:

> I see the following at the end of configuring:
>
> checking dependency style of g++... (cached) gcc3
> checking that generated files are newer than configure... done
> configure: creating ./config.status
> config.status: creating Makefile
> config.status: executing depfiles commands
> + cat .deps/main.Po
> # dummy
> + make
> g++ -DPACKAGE_NAME=3D\"main\" -DPACKAGE_TARNAME=3D\"main\" -=20
> DPACKAGE_VERSION=3D\"1\" -DPACKAGE_STRING=3D\"main\ 1\" -DPACKAGE_BUGRE=
PORT=3D\"\" =20
> -DPACKAGE_URL=3D\"\" -DPACKAGE=3D\"main\" -DVERSION=3D\"1\" -I.=C2=A0=C2=
=A0=C2=A0=C2=A0 -g -O2 -MT =20
> main.o -MD -MP -MF .deps/main.Tpo -c -o main.o main.cc
> mv -f .deps/main.Tpo .deps/main.Po
> g++=C2=A0 -g -O2=C2=A0=C2=A0 -o main main.o
> + cat .deps/main.Po
> main.o: main.cc /usr/include/stdc-predef.h main.h
> /usr/include/stdc-predef.h:
> main.h:
>
> In other words, configure creates config.status and calls config.status =20
> depfiles, which creates a dummy version of .deps/main.Po. If that didn'=
t =20
> happened make would complain about the 'include .deps/main.Po' in 'Make=
file' =20
> and I believe that only happens when .deps/main.Po does not already exi=
st. =20
> Then when g++ is creating main.o it also generates a proper version =20
> of .deps/main.Po.

But if "make clean" should be undoing what "make" did, then, logically, =20
"make clean" should end up putting the stub into .deps/main.Po, instead o=
f =20
leaving the real dependencies that "make" wrote in there.

Or, if configure did /not/ do anything, and, just somehow, .deps files we=
re =20
created automatically if they did not exist, and, if somehow, this was do=
ne =20
before include hollered, then this would work.

> If 'make dist' were to remove the .deps files as you suggest, then 'mak=
e =20
> clean; make all' would fail because a file included into the 'Makefile' =
at =20
> the time of 'make all' that would be quite unexpected behavior.

Odd. I did not notice any difficulties in running "make" after running "r=
m -=20
rf .deps" myself, after a "make clean".

Looks like there's a rule that creates the .deps files if they are missin=
g, =20
so there's no need to bother configure with this task. After "make clean"=
, =20
"rm -rf .deps", "make", then an immediate CTRL-C:

$ ls .deps | wc -l
47

I definitely did not just compile 47 files, didn't even get to the first =20
base.

Looking at what I have in the Makefile, I see:

am__depfiles_remade =3D [ long list of ./$(DEPDIR) files ]

[ bunch of stuff ]

$(am__depfiles_remade):
        @$(MKDIR_P) $(@D)
        @echo '# dummy' >$@-t && $(am__mv) $@-t $@

So, it seems to me that configure can avoid dealing with depfiles at all, =20
and it's safe to have "make clean" get rid of them, they'll just be remad=
e =20
on the next "make".

The only puzzle is that the [ bunch of stuff ] does have these includes, =
in =20
fact they immediately precede the above rule. Yet, again, my "make clean" =20
and "rm -rf .deps" did not break anything, the subsequent "make" rebuilt =20
everything, despite the Makefile referencing a (temporarily) nonexistent =20
include files.

After digging through make's documentation, a clue emerged:

#    If an included makefile cannot be found in any of these directories
# it is not an immediately fatal error; processing of the makefile
# containing the 'include' continues.  Once it has finished reading
# makefiles, 'make' will try to remake any that are out of date or don't
# exist.  *Note How Makefiles Are Remade: Remaking Makefiles.  Only after
# it has failed to find a rule to remake the makefile, or it found a rule
# but the recipe failed, will 'make' diagnose the missing makefile as a
# fatal error.

So, a nonexistent include is not an error if make can find a rule that =20
builds it. It then gets suppressed.

Oh, and there's also a:

 -include FILENAMES=E2=80=A6

which never complains about missing makefiles... how about that...

--=_ripper.email-scan.com-3232-1745032612-0001
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQRupkKLJP96aW75pIOKYPgoojZS4gUCaAMVpAAKCRCKYPgoojZS
4ojNAQCyDy0um45oCsBXPzfC4bOc8yqygYkx2JLG/uV2CaI6zwEA/UcJKe7n0SC7
Vc6zHhvQu5ePUkqKEpuH+P++usQ5ZQ4=
=Ktvf
-----END PGP SIGNATURE-----

--=_ripper.email-scan.com-3232-1745032612-0001--