Обсуждение: Ignoring some binaries generated in src/test

Hi all,

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?
Regards,
--
Michael

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

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

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

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