Ignoring some binaries generated in src/test

Michael Paquier <michael.paquier@gmail.com> writes:

A couple of binaries in src/test, that are not part of the main make
flow, can be built but they are actually not ignored in the tree:
examples/testlibpq
examples/testlibpq2
examples/testlibpq3
examples/testlibpq4
examples/testlo
examples/testlo64
locale/test-ctype
thread/thread_test
I recall that some of them were target for removal, still shouldn't
they have their own entries in a .gitignore, like in the patch
attached?

Perhaps, but if we're going to support doing a make in those
subdirectories, I think it would also be appropriate to fix
src/test/Makefile so that "clean" and related targets recurse to
those subdirectories.

The current logic in src/test/Makefile, particularly the way that
the modules subdirectory is handled, seems pretty ugly/convoluted
anyway. I wonder why it was done that way rather than just ensuring
that modules/ doesn't do anything for "make install"?

We'd still need special cases for examples/ et al because we don't want
them built during "make all", but I think just adding them to
ALWAYS_SUBDIRS might suffice.

regards, tom lane

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

Tom Lane wrote:

The current logic in src/test/Makefile, particularly the way that
the modules subdirectory is handled, seems pretty ugly/convoluted
anyway. I wonder why it was done that way rather than just ensuring
that modules/ doesn't do anything for "make install"?

Because we do want to have the Makefile in src/test/modules to install
the modules if "make install" is invoked there. That way, you can run
"make -C src/test/modules install installcheck", and it works.

--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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

Alvaro Herrera <alvherre@2ndquadrant.com> writes:

Tom Lane wrote:

The current logic in src/test/Makefile, particularly the way that
the modules subdirectory is handled, seems pretty ugly/convoluted
anyway. I wonder why it was done that way rather than just ensuring
that modules/ doesn't do anything for "make install"?

Because we do want to have the Makefile in src/test/modules to install
the modules if "make install" is invoked there. That way, you can run
"make -C src/test/modules install installcheck", and it works.

OK. I still wonder if there isn't a better way to get that effect, but
I left it alone for now. I committed Michael's new .gitignore files and
fixed the Makefiles so that "make clean" and friends clean up properly.

regards, tom lane

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

On Sat, Apr 25, 2015 at 6:14 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Alvaro Herrera <alvherre@2ndquadrant.com> writes:

Tom Lane wrote:

The current logic in src/test/Makefile, particularly the way that
the modules subdirectory is handled, seems pretty ugly/convoluted
anyway. I wonder why it was done that way rather than just ensuring
that modules/ doesn't do anything for "make install"?

Because we do want to have the Makefile in src/test/modules to install
the modules if "make install" is invoked there. That way, you can run
"make -C src/test/modules install installcheck", and it works.

OK. I still wonder if there isn't a better way to get that effect, but
I left it alone for now. I committed Michael's new .gitignore files and
fixed the Makefiles so that "make clean" and friends clean up properly.

Thanks.
--
Michael

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