Re: pg_upgrade versus MSVC build scripts - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: pg_upgrade versus MSVC build scripts
Date
Msg-id 201005122157.o4CLvW205301@momjian.us
Whole thread Raw
In response to Re: pg_upgrade versus MSVC build scripts  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pg_upgrade versus MSVC build scripts
Re: pg_upgrade versus MSVC build scripts
List pgsql-hackers
Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
> > Tom Lane wrote:
> >> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> >>> Do you mean contrib/pg_upgrade/somelib?  If so, +1.
> >> 
> >> Hmm.  I had been thinking the other way, but I'll see if that can be
> >> made to work.
> 
> > Not sure this will work on its own with the MSVC build system - I don't 
> > think it's set up for sub-modules.
> 
> Oh, right.  Since the entire point here is to *not* require new
> buildsystem infrastructure for pg_upgrade, I'm back to thinking that
> a separate contrib module is the way to go.

Uh, if you do 'make install' in the pg_upgrade directory, would it also
install the shared lib contrib?  If not, it seems kind of complicated
from a user perspective.  Can't we pass a 'make' down into a
subdirectory and have a separate Makefile just run?  pg_migrator had
this rule:
all install installdirs uninstall distprep clean distclean maintainer-clean:        $(MAKE) -C src $@        $(MAKE) -C
func$@
 


--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: pg_upgrade versus MSVC build scripts
Next
From: Andrew Dunstan
Date:
Subject: Re: pg_upgrade versus MSVC build scripts