A look at the MSVC buildfarm members shows that they are not building
most of the files added to contrib/pg_upgrade. The reason seems to be
that that module tries to build both an executable program *and* a
shared library, which it does by dint of setting both PROGRAM and
MODULES in its Makefile.
Excerpts from Tom Lane's message of mié may 12 14:07:13 -0400 2010:
We could try to make this a supported build arrangement, but I'm
inclined to think that a cleaner solution is to split out the loadable
module as a separate contrib subdirectory. Thoughts?
Do you mean
Alvaro Herrera alvhe...@alvh.no-ip.org writes:
Excerpts from Tom Lane's message of mié may 12 14:07:13 -0400 2010:
We could try to make this a supported build arrangement, but I'm
inclined to think that a cleaner solution is to split out the loadable
module as a separate contrib subdirectory.
Tom Lane wrote:
Alvaro Herrera alvhe...@alvh.no-ip.org writes:
Excerpts from Tom Lane's message of mié may 12 14:07:13 -0400 2010:
We could try to make this a supported build arrangement, but I'm
inclined to think that a cleaner solution is to split out the loadable
module as a
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
Alvaro Herrera alvhe...@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
Tom Lane wrote:
A look at the MSVC buildfarm members shows that they are not building
most of the files added to contrib/pg_upgrade. The reason seems to be
that that module tries to build both an executable program *and* a
shared library, which it does by dint of setting both PROGRAM and
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
Tom Lane wrote:
Alvaro Herrera alvhe...@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
Bruce Momjian br...@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?
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 $@
Tom Lane wrote:
Bruce Momjian br...@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
Bruce Momjian br...@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
Tom Lane wrote:
Bruce Momjian br...@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
Bruce Momjian br...@momjian.us writes:
Now that it only targets the packaged version, I can do with a single
shared object, but maybe it needs to be more generic, like
pg_upgrade_tools.so or something like that.
+1 for pg_upgrade_tools or pg_upgrade_support or some such name.
I realize we
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
Now that it only targets the packaged version, I can do with a single
shared object, but maybe it needs to be more generic, like
pg_upgrade_tools.so or something like that.
+1 for pg_upgrade_tools or pg_upgrade_support or some such
On May 12, 2010, at 4:07 PM, Bruce Momjian wrote:
I like 'pg_upgrade_support'. I could also do 'pg_upgrade_funcs'.
I misread the second one at a glance, so I recommend the first.
Best,
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian br...@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 ---
16 matches
Mail list logo
