GNU bug report logs - #77897
"make clean" should do a "rm -rf .deps"

Previous Next

Full log

Message #14 received at 77897 <at> debbugs.gnu.org (full text, mbox):

From: Sam Varshavchik <mrsam <at> courier-mta.com>
To: Peter Johansson <trojkan <at> gmail.com>
Cc: 77897 <at> debbugs.gnu.org
Subject: Re: bug#77897: "make clean" should do a
 "rm -rf .deps"
Date: Fri, 18 Apr 2025 21:21:02 -0400

[Message part 1 (text/plain, inline)]

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

[Message part 2 (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.