Prev: multibyte charater set in levenshtein function
Next: [HACKERS] pg_dump should not try CREATE OR REPLACE LANGUAGE < 9.0
From: Bruce Momjian on 12 May 2010 17:57
Tom Lane wrote:
> Andrew Dunstan <andrew(a)dunslane.net> writes:
> > Tom Lane wrote:
> >> Alvaro Herrera <alvherre(a)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(a)momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

From: Andrew Dunstan on 12 May 2010 18:05


Bruce Momjian wrote:
> 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 $@
>
>

Yes, you can on Unix, of course. But I'm pretty sure it won't work with
the MSVC build system.

cheers

andrew

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

From: Tom Lane on 12 May 2010 18:07
Bruce Momjian <bruce(a)momjian.us> writes:
> 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?

No. You're still failing to consider the MSVC build case.

I think that anyone who can cope with building pg_upgrade from source
can deal with building pg_upgrade_sysoids in addition, especially if
the documentation tells him to. In practice, 99% of users just build
(or install) all of contrib/ at once, I think, so it's unlikely to
affect them much anyway.

I understand your desire to save one step in the build process, but
I don't think it's worth contorting our build system for --- especially
since pg_migrator isn't likely to stay in contrib indefinitely.

regards, tom lane

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

From: Bruce Momjian on 12 May 2010 18:35
Tom Lane wrote:
> Bruce Momjian <bruce(a)momjian.us> writes:
> > 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?
>
> No. You're still failing to consider the MSVC build case.
>
> I think that anyone who can cope with building pg_upgrade from source
> can deal with building pg_upgrade_sysoids in addition, especially if
> the documentation tells him to. In practice, 99% of users just build
> (or install) all of contrib/ at once, I think, so it's unlikely to
> affect them much anyway.

If we make it /contrib/pg_upgrade_shlibs, will it need a documentation
page? Can I built multiple shared libs in there if needed? If we put
it under /contrib/pg_upgrade, can it still be a separate build step?
Would that work?

> I understand your desire to save one step in the build process, but
> I don't think it's worth contorting our build system for --- especially
> since pg_migrator isn't likely to stay in contrib indefinitely.

OK.

--
Bruce Momjian <bruce(a)momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

From: Tom Lane on 12 May 2010 18:42
Bruce Momjian <bruce(a)momjian.us> writes:
> If we make it /contrib/pg_upgrade_shlibs, will it need a documentation
> page?

I don't see a need for that. Also, why would you make the directory
name different from the name of the shlib it's building --- or are
you having second thoughts about the present name?

> Can I built multiple shared libs in there if needed?

No, but why would you need more than one? What you might need
(and can't have with the present hack) is more than one .o file
getting built into the shared library.

> If we put
> it under /contrib/pg_upgrade, can it still be a separate build step?
> Would that work?

Isn't that the same idea you just proposed?

regards, tom lane

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

First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: multibyte charater set in levenshtein function
Next: [HACKERS] pg_dump should not try CREATE OR REPLACE LANGUAGE < 9.0