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

From Peter Eisentraut
Subject Re: make depend (Re: Coming attractions: VPATH build; make variables issue)
Date
Msg-id Pine.LNX.4.21.0010192213130.777-100000@peter.localdomain
Whole thread Raw
In response to Re: make depend (Re: Coming attractions: VPATH build; make variables issue)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: make depend (Re: Coming attractions: VPATH build; make variables issue)
List pgsql-hackers
Tom Lane writes:

> One thought here: "make depend" has the advantage of being
> non-intrusive, in the sense that you're not forced to use it and if
> you don't use it it doesn't cost you anything.  In particular,
> non-developer types probably just want to build from scratch when they
> get a new distribution --- they don't want to expend cycles on making
> useless (for them) dependency files, and they most certainly don't want
> to be forced to use gcc, nor to install a makedepend tool.

All of this is true for the "advanced" method as well.

The only advantage of `make depend' is that you can run it after you have
already built.  But then you have to remember to re-run it all the time,
otherwise the point of having accurate dependencies is gone.  So this
might be useful for someone installing a patch into a header file and not
wanting to rebuild from scratch, but that's about it.

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.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/



pgsql-hackers by date:

Previous
From: "Vadim Mikheev"
Date:
Subject: Re: AW: Backup, restore & pg_dump
Next
From: "Matthew H. North"
Date:
Subject: RE: [ADMIN] Automation/scheduling of Backup stratetgy