Re: make depend (Re: Coming attractions: VPATH build; make variables issue) - Mailing list pgsql-hackers

From Brook Milligan
Subject Re: make depend (Re: Coming attractions: VPATH build; make variables issue)
Date
Msg-id 200010201418.IAA03618@biology.nmsu.edu
Whole thread Raw
In response to Re: make depend (Re: Coming attractions: VPATH build; make variables issue)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Peter Eisentraut <peter_e@gmx.net> writes:  > What we could do is ship the dependencies (.deps/*.P) in the tarball.
 > That would require running an entire build before making a tarball, but it  > would be a nice service to users.
 
  Hm.  It might be handy for people not using gcc, since they'd have no  easy way to build dependencies for themselves.
Do you have an idea  how much it'd bloat the tarball to do that?
 

Isn't the basic idea to write Makefile targets to remake dependency
files when they are out of date with code?  Won't those targets
involve implicit rules for going, for example, from *.c -> *.d (or
whatever convention you use for dependency files)?  Don't these
Makefiles also have a list of srcs to be built, e.g., a make variable
that defines a list of *.c filename?

If so, can't you just implement a depend: target as
  ${DEPEND_FILES}+=${SRCS:%c=%d}  depend: ${DEPEND_FILES}  .SUFFIXES: .c .d  .c.d:gcc -M ...  .include
"${DEPEND_FILES}"

For gmake users, all the magic happens automatically.  Prior to
distribution, just do make depend to get all the *.d files to include
in the tarball.  For non-gmake users, all the *.d files already exist
in the source.  If they make changes, they can run make depend
manually.

Sorry if this is what you had in mind already, but the discussion
seemed to imply that you can't have it both ways.

Cheers,
Brook


pgsql-hackers by date:

Previous
From: Thomas Lockhart
Date:
Subject: Re: Re: pg_dump docs
Next
From: Tatsuo Ishii
Date:
Subject: to_char() dumps core