pg_migrator mention in documentation

[Bruce Momjian-5]

Joe Conway wrote:

> Bruce Momjian wrote:
> > Tom Lane wrote:
> >> Alvaro Herrera <alvherre@...> writes:
> >>> Consistency here is pointless.  IIRC the dual method is used in contrib
> >>> because people did not trust the PGXS stuff enough to rip the original
> >>> Make code out; or maybe because people did not want PGXS to become the
> >>> default build method, but they allowed it to be used in contrib as a
> >>> test bed that PGXS worked.
> >> The main reason contrib still has the alternate method is that PGXS
> >> doesn't really work until after you've installed the core build.
> >> For modules distributed separately from core, it doesn't seem that
> >> exciting to be able to build using the contrib method.
> >>
> >> Now, having said that, I'm personally interested in being able to build
> >> pg_migrator against an uninstalled source tree, because I foresee
> >> needing to do that for RPM packaging purposes.  But I could easily patch
> >> the makefiles if needed to make that happen.  I don't think this case
> >> should drive the choice of what's the default or common method.
> >
> > Well, PGXS is now the recommended install method in the pg_migrator
> > INSTALL file.  What other changes should I make?
>
> Since PGXS does not work under Windows, I think the only way to build
> non-contrib extensions on Windows is the contrib way (i.e. place in
> contrib folder and use contrib style Makefile).

I assume this work too:

        gmake top_builddir=/usr/src/pgsql install

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

  + If your life is a hard drive, Christ can be your backup. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Peter Eisentraut-2]

On Friday 03 July 2009 02:28:22 Bruce Momjian wrote:
> I looked at that and the problem is that pg_migrator must be built
> against the _new_ source tree, and will issue an error and exit if it
> isn't.  The problem with PGXS is it silently chooses the source tree to
> use based on which pg_config it finds in its path first;  that seems
> error-prone.  Any ideas for a clearer way to specify pg_config, and is
> that really helping things if the user has to specify it?

The standard way to do that is

make PG_CONFIG=/some/where/pg84/pg_config

> As you can
> see, pg_migrator has the requirement of running in a multi-pg_config
> binary environment, so it has extra complexity that might make pg_config
> an undesirable option to be promoted first.

It's certainly easier to do the above than having to download, configure, and
modify the PostgreSQL source tree, I think.


--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[Bruce Momjian-5]

Peter Eisentraut wrote:

> On Friday 03 July 2009 02:28:22 Bruce Momjian wrote:
> > I looked at that and the problem is that pg_migrator must be built
> > against the _new_ source tree, and will issue an error and exit if it
> > isn't.  The problem with PGXS is it silently chooses the source tree to
> > use based on which pg_config it finds in its path first;  that seems
> > error-prone.  Any ideas for a clearer way to specify pg_config, and is
> > that really helping things if the user has to specify it?
>
> The standard way to do that is
>
> make PG_CONFIG=/some/where/pg84/pg_config
>
> > As you can
> > see, pg_migrator has the requirement of running in a multi-pg_config
> > binary environment, so it has extra complexity that might make pg_config
> > an undesirable option to be promoted first.
>
> It's certainly easier to do the above than having to download, configure, and
> modify the PostgreSQL source tree, I think.

I see you are replying to an old email;  the current installer
instrutions are:

        (7)  Build pg_migrator
       
        For pg_migrator source installs, keep in mind the compile must use the
        _new_ PostgreSQL source directory and be installed in the new Postgres
        install directory.
       
        The simplest build option is to use PGXS:
       
                gmake USE_PGXS=1 PG_CONFIG=/usr/local/pgsql/bin/pg_config install
       
       
        Another option is to point to the top of the new PostgreSQL source tree
        by running something like:
       
                gmake top_builddir=/usr/src/pgsql install
       
        Replace '/usr/src/pgsql' with your new source directory.  pg_migrator
        also understands the 'prefix=' specification if you installed Postgres
        in a custom location.

pg_migrator does need a compiled backend source tree to be compiled,
e.g. it needs libpgport and access to backend C defines.

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

  + If your life is a hard drive, Christ can be your backup. +

--
Sent via pgsql-hackers mailing list (pgsql-hackers@...)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers