[lug] OT: Makefile oddity

[D. Stimits]

I've decided it is probably ok to assume GNU make and gcc/g++ on this
project. At least all of the primary authors use g++ and GNU make, and
although a dependency file is a generated file and probably should not
be shipped normally, I think the non-GNU variants could still use a
dependency file that is generated by GNU make, so it probably is not
much of a limitation.

So I have what I hope is one last hurdle here to emerging from the Dark
Ages of non-cvs and tons of sym links in hard-to-package layouts. Using
something like this as an example of generating the dependencies, I have
a problem due to intermediate object files going to a separate
directory:

depend:
	echo "# make/utils/Makefile.dep" > Makefile.dep
	echo "# This file is a generated file." >> Makefile.dep
	echo "" >> Makefile.dep
	g++ ${CXXFLAGS} \
		${INC} \
		-MM -MG ${SRC_UTILS} >> Makefile.dep
	echo "" >> Makefile.dep


What this above does is 100% correct, with one exception. It assumes my
dependency is for the current directory, e.g., if I have Abc.cxx, the
output is Abc.o (this particular build directory has no linking, it is
all intermediate object code output), but the actual build lines are
using a relative directory, e.g., "../obj/". So instead of a dependency
"Abc.o: Abc.cxx", what I need is a prefix like "../obj/Abc.o: Abc.cxx".
There are lots of ways to do this if it was an actual compile line, but
I'm not sure how to do this in a g++ -MM -MG line. It's rather likely
that if someone bothered to add -MM -MG to g++, then there is also a way
to do this naming a relative path directory as well. Does anyone know if
there is a particularly suitable way to prefix this relative path for my
dependencies? Or is it a case of requiring something additional, such as
pipes to sed or awk or perl?

D. Stimits, stimits at idcomm.com

Ken Weinert wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Saturday 20 Apr 2002 17:43, you wrote:
> > >>>>> ">" == D Stimits <stimits at idcomm.com> writes:
> >
> > Tom> However, there's a bug here.  It is the classic recursive make
> > Tom> bug: you only have a dependency on the .cpp file.  So if you
> > Tom> `touch config.h', nothing will be rebuilt -- which is wrong.
> >
> > >> I don't really consider this a bug, just a limitation of the
> > >> technology.  makedepend would almost work, except it is designed
> > >> for C instead of C++, and fails to deal properly with .cpp or .cxx
> > >> extensions.
> 
>         I see that according to the above paper my method can suffer from some
> problems, but in the general case it works well for me.
> 
>         Here's an excerpt from a Makefile in a current project:
> 
> include ../../make.cfg
> 
> SRC =   attributes.c depth.c logit.c power.c mapstuff.c bprintf.c \
>         walls.c getGameInfo.c getNextLine.c palette.c sph.c \
>         getPlayerInfo.c getUnits.c support.c strupr.c rollDie.c storage.c
> 
> OBJ = $(SRC:.c=.o)
> 
> all $(ADJROOT)/lib/libbattle.a : $(ADJROOT)/lib/libbattle.a($(OBJ))
> 
> clean :
>         rm -f *~ *.o *.d $(ADJROOT)/lib/libbattle.a
> 
> include $(OBJ:.o=.d)
> 
> %.d: %.c
>         $(CC) -M -MG $(CFLAGS) $(INCLUDES) $(LOCAL_DEFINES) $< > $@
> 
>         Yes, it's gcc/g++ dependent - that's a feature, not a bug :)  The -M flag
> works for C++ files and it will include the-not-.h-terminated-filename
> headers (although the -MG explicitly removes the dependency on system
> headers).
> 
> - --
> Ken Weinert   mc at morat.net
> GnuPG KeyID: 9274F1CE           GnuPG available at http://www.gnupg.org/
> GnuPG Key Fingerprint: 1D87 3720 BB77 4489 A928  79D6 F8EC DD76 9274 F1CE
> E Pluribus Modem
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
> 
> iEYEARECAAYFAjzD9uIACgkQ+OzddpJ08c5XKACfUViC57p5NnVBwPRf2BH12qaj
> Ca8AoJJv5bf15XKqvF8mwkXNit7+YoLi
> =mT08
> -----END PGP SIGNATURE-----
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug