GNU bug report logs -
#77897
"make clean" should do a "rm -rf .deps"
Previous Next
Full log
Message #17 received at 77897 <at> debbugs.gnu.org (full text, mbox):
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
This bug report was last modified 28 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.