Thread: 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
Attachment
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