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

Previous Next

To reply to this bug, email your comments to 77897 AT debbugs.gnu.org.
There is no need to reopen the bug first.

Toggle the display of automated, internal messages from the tracker.

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

From: Sam Varshavchik <mrsam <at> courier-mta.com>
To: bug-automake <at> gnu.org
Subject: "make clean" should do a "rm -rf
 .deps"
Date: Fri, 18 Apr 2025 07:56:49 -0400

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

.deps/filename gets created during building with --enable-dependency- 
tracking and should get removed by make clean. But it does not. For example:

main.h:

int helloworld();

main.c:

#include <main.h>

int helloworld()
{
   return 0;
}

int main()
{
   helloworld();
}

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

Now: 1) 'rm -f main.h"  2) Remove the #include

Then try to build this:

make clean
make

Will fail because that dependency exists and make does not know how to build  
main.h. I have to rm -rf .deps myself.

automake 1.16.5

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

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

From: Nick Bowler <nbowler <at> draconx.ca>
To: Sam Varshavchik <mrsam <at> courier-mta.com>
Cc: 77897 <at> debbugs.gnu.org
Subject: Re: bug#77897: "make clean" should do a "rm -rf .deps"
Date: Fri, 18 Apr 2025 09:44:50 -0400

On Fri, Apr 18, 2025 at 07:56:49AM -0400, Sam Varshavchik wrote:
> .deps/filename gets created during building with --enable-dependency-tracking
> and should get removed by make clean. But it does not. For example:

Use 'make distclean' to remove depfiles.

Cheers,
  Nick

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

From: Peter Johansson <trojkan <at> gmail.com>
To: Sam Varshavchik <mrsam <at> courier-mta.com>, 77897 <at> debbugs.gnu.org
Subject: Re: bug#77897: "make clean" should do a "rm -rf .deps"
Date: Sat, 19 Apr 2025 08:38:42 +1000

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.


> Now: 1) 'rm -f main.h"  2) Remove the #include
>
> Then try to build this:
>
> make clean
> make
>
> Will fail because that dependency exists and make does not know how to 
> build main.h. I have to rm -rf .deps myself.
>
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.

Cheers,

Peter

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)]

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

From: Peter Johansson <trojkan <at> gmail.com>
To: Sam Varshavchik <mrsam <at> courier-mta.com>
Cc: 77897 <at> debbugs.gnu.org
Subject: Re: bug#77897: "make clean" should do a "rm -rf .deps"
Date: Sat, 19 Apr 2025 12:49:54 +1000

On 4/19/25 11:21, Sam Varshavchik wrote:
> 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. 


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=\"main\" -DPACKAGE_TARNAME=\"main\" 
-DPACKAGE_VERSION=\"1\" -DPACKAGE_STRING=\"main\ 1\" 
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"main\" 
-DVERSION=\"1\" -I.     -g -O2 -MT main.o -MD -MP -MF .deps/main.Tpo -c 
-o main.o main.cc
mv -f .deps/main.Tpo .deps/main.Po
g++  -g -O2   -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 
depfiles, which creates a dummy version of .deps/main.Po. If that didn't 
happened make would complain about the 'include .deps/main.Po' in 
'Makefile' and I believe that only happens when .deps/main.Po does not 
already exist. Then when g++ is creating main.o it also generates a 
proper version of .deps/main.Po.

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

Peter

Message #20 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 23:16:52 -0400

[Message part 1 (text/plain, 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=\"main\" -DPACKAGE_TARNAME=\"main\" - 
> DPACKAGE_VERSION=\"1\" -DPACKAGE_STRING=\"main\ 1\" -DPACKAGE_BUGREPORT=\"\"  
> -DPACKAGE_URL=\"\" -DPACKAGE=\"main\" -DVERSION=\"1\" -I.     -g -O2 -MT  
> main.o -MD -MP -MF .deps/main.Tpo -c -o main.o main.cc
> mv -f .deps/main.Tpo .deps/main.Po
> g++  -g -O2   -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  
> depfiles, which creates a dummy version of .deps/main.Po. If that didn't  
> happened make would complain about the 'include .deps/main.Po' in 'Makefile'  
> and I believe that only happens when .deps/main.Po does not already exist.  
> Then when g++ is creating main.o it also generates a proper version  
> of .deps/main.Po.

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

Or, if configure did /not/ do anything, and, just somehow, .deps files were  
created automatically if they did not exist, and, if somehow, this was done  
before include hollered, then this would work.

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

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

Looks like there's a rule that creates the .deps files if they are missing,  
so there's no need to bother configure with this task. After "make clean",  
"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  
base.

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

am__depfiles_remade = [ 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,  
and it's safe to have "make clean" get rid of them, they'll just be remade  
on the next "make".

The only puzzle is that the [ bunch of stuff ] does have these includes, in  
fact they immediately precede the above rule. Yet, again, my "make clean"  
and "rm -rf .deps" did not break anything, the subsequent "make" rebuilt  
everything, despite the Makefile referencing a (temporarily) nonexistent  
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  
builds it. It then gets suppressed.

Oh, and there's also a:

-include FILENAMES…

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

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

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

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

On 4/19/25 13:16, Sam Varshavchik wrote:
>
> 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.
>
This is for GNU make, I suppose, but I doubt that behavior is portable 
and can be assumed by Automake.


> So, a nonexistent include is not an error if make can find a rule that 
> builds it. It then gets suppressed.
>
> Oh, and there's also a:
>
> -include FILENAMES…
>
> which never complains about missing makefiles... how about that...
That is definitely not portable.

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

From: Karl Berry <karl <at> freefriends.org>
To: mrsam <at> courier-mta.com, 77897 <at> debbugs.gnu.org
Subject: Re: bug#77897: "make clean" should do a "rm -rf .deps"
Date: Mon, 21 Apr 2025 14:42:15 -0600

Sam, if your situation needs to remove .deps at make clean, how about:

clean-local:
       rm -rf .deps

It does not seem plausible to me to change automake's behavior in this
regard at this late date. It would surely cause a lot of trouble in a
lot of packages. --best, karl.

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

From: Sam Varshavchik <mrsam <at> courier-mta.com>
To: Karl Berry <karl <at> freefriends.org>
Cc: 77897 <at> debbugs.gnu.org
Subject: Re: bug#77897: "make clean" should do a
 "rm -rf .deps"
Date: Mon, 21 Apr 2025 17:59:47 -0400

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

Karl Berry writes:

> Sam, if your situation needs to remove .deps at make clean, how about:
>
> clean-local:
>        rm -rf .deps
>
> It does not seem plausible to me to change automake's behavior in this
> regard at this late date. It would surely cause a lot of trouble in a
> lot of packages. --best, karl.

Yeah, that's the solution that I think I'll go with.

It's just that in my worldview there's only one make. One make to rule them  
all. One make to compile them. One make to bring all dependencies together,  
and with the linker bind them.

gmake.

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

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

From: Karl Berry <karl <at> freefriends.org>
To: 77897-done <at> debbugs.gnu.org
Subject: Re: bug#77897: "make clean" should do a
         "rm -rf .deps"
Date: Tue, 22 Apr 2025 15:27:21 -0600

Previous Next

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