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





Reply via email to