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-545122-1745025662-0001
Content-Type: text/plain; format=flowed; delsp=yes; charset="UTF-8"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Peter Johansson writes:

> Hi Sam,
>
> On 4/18/25 21:56, Sam Varshavchik wrote:
>>
>> Set up a minimal Makefile.am and configure.ac to build this. Building this  
>> will create .deps/<filename> with a:
>>
>> main.o: main.h main.c
>>
> When I do this with GCC, the .deps/<filename> also contains a line
>
> main.h:
>
> and I have no problem removing main.h and the #include and just run 'make'.  
> If you don't have that line (main.h:), it's bug in your compiler and I  
> suggest you report it.

I'm guilty of wasting a little bit of time with a simplified example.

The real example involves a git repo and multiple branches, one branch has C  
code, another branch has C++ code. They compile to the same .o-s. That is,  
one branch has main.c compiling into main.o, and the other branch has  
main.cpp compiling into main.o. Each branch has the appropriate Makefile.am  
reflecting what's on that branch.

So now when I switch branches things get stuck. What gets included  
from .deps/filename are, basically:

main.o: main.c main.h <a bunch of other header files>

there's no main.c any more. This branch I'm now on has main.cpp. Even though  
the Makefile.am now reflects that, things won't go anywhere unless I  
manually rm -rf .deps.

How about we try another contrived example. Just a main.c with

int main()
{
    return 0;
}

and

noinst_PROGRAMS=main

main_SOURCES=main.c

Let's now run make (in addition to automake/autoconf) and build this  
successfully.

Next, rename main.c to main.cpp and update Makefile.am to

noinst_SOURCES=main.cpp

What should happen right now by running "make":

1) Rules that build out of date Makefile.in and Makefile, from Makefile.am  
get triggered. The new, correct, Makefile should get built automatically,  
then

2) The existing dependency from .deps is going to get pulled in, declaring  
main.o's dependency on main.c, which does not exist any more. "make clean"  
won't help here.

> As a rule of thumb 'make clean' does not remove things that were created  
> during configure (or upstream), but obviously depends on how people write  
> the Makefile.am.

I'm just using old-fashioned autoconf+automake+libtool-generated rules,  
nothing more.

I don't see my .deps's contents getting created during configure. What I see  
is happening is automake-generated makefile's compile command invokes gcc  
with the -M option in order to generate the .deps file. The contents of.deps  
are created by a plain, garden variety, "make" (with a suitable -j option).

Additionally, automake-generated Makefile.am do /not/ include .deps in "make  
dist"-generated tarballs. Perhaps in some ancient times it did, and the  
contents of .deps arrived in the same tarball, and hence "make clean" was  
hesitant to remove them for that reason. But, right now, .deps rules are  
generated as part of compiling. "make clean" removes everything that's  
generated at compile time, except for .deps


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

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

iHUEABYKAB0WIQRupkKLJP96aW75pIOKYPgoojZS4gUCaAL6fgAKCRCKYPgoojZS
4hQqAP98vR0mfwWGDTT3LrNPrOs2ESkCWXfcPXXmSfXkZNUSQgD9ErOyYp5eduDV
39QakyO0j7xzswCL0/sx1T5FrJaKOgA=
=2ixe
-----END PGP SIGNATURE-----

--=_ripper.email-scan.com-545122-1745025662-0001--