Object files generated by ecpg test suite not ignored on Windows
Hi all,
When running the test suite of ecpg, build generates a set of obj
files and it happens that those files are not ignored in the code
tree.
Patch is attached.
Regards,
--
Michael
Attachments:
20150308_ecpg_test_ignore_obj.patchtext/x-diff; charset=US-ASCII; name=20150308_ecpg_test_ignore_obj.patchDownload
diff --git a/src/interfaces/ecpg/test/compat_informix/.gitignore b/src/interfaces/ecpg/test/compat_informix/.gitignore
index f97706b..6086676 100644
--- a/src/interfaces/ecpg/test/compat_informix/.gitignore
+++ b/src/interfaces/ecpg/test/compat_informix/.gitignore
@@ -1,18 +1,27 @@
/charfuncs
/charfuncs.c
+/charfuncs.obj
/dec_test
/dec_test.c
+/dec_test.obj
/describe
/describe.c
+/describe.obj
/rfmtdate
/rfmtdate.c
+/rfmtdate.obj
/rfmtlong
/rfmtlong.c
+/rfmtlong.obj
/rnull
/rnull.c
+/rnull.obj
/sqlda
/sqlda.c
+/sqlda.obj
/test_informix
/test_informix.c
+/test_informix.obj
/test_informix2
/test_informix2.c
+/test_informix2.obj
diff --git a/src/interfaces/ecpg/test/connect/.gitignore b/src/interfaces/ecpg/test/connect/.gitignore
index e0639f3..fe33bba 100644
--- a/src/interfaces/ecpg/test/connect/.gitignore
+++ b/src/interfaces/ecpg/test/connect/.gitignore
@@ -1,10 +1,15 @@
/test1
/test1.c
+/test1.obj
/test2
/test2.c
+/test2.obj
/test3
/test3.c
+/test3.obj
/test4
/test4.c
+/test4.obj
/test5
/test5.c
+/test5.obj
diff --git a/src/interfaces/ecpg/test/pgtypeslib/.gitignore b/src/interfaces/ecpg/test/pgtypeslib/.gitignore
index 2987fef..787c6b2 100644
--- a/src/interfaces/ecpg/test/pgtypeslib/.gitignore
+++ b/src/interfaces/ecpg/test/pgtypeslib/.gitignore
@@ -1,10 +1,15 @@
/dt_test
/dt_test.c
+/dt_test.obj
/dt_test2
/dt_test2.c
+/dt_test2.obj
/nan_test
/nan_test.c
+/nan_test.obj
/num_test
/num_test.c
+/num_test.obj
/num_test2
/num_test2.c
+/num_test2.obj
diff --git a/src/interfaces/ecpg/test/preproc/.gitignore b/src/interfaces/ecpg/test/preproc/.gitignore
index ffca98e..f274216 100644
--- a/src/interfaces/ecpg/test/preproc/.gitignore
+++ b/src/interfaces/ecpg/test/preproc/.gitignore
@@ -1,24 +1,36 @@
/array_of_struct
/array_of_struct.c
+/array_of_struct.obj
/autoprep
/autoprep.c
+/autoprep.obj
/comment
/comment.c
+/comment.obj
/cursor
/cursor.c
+/cursor.obj
/define
/define.c
+/define.obj
/init
/init.c
+/init.obj
/outofscope
/outofscope.c
+/outofscope.obj
/pointer_to_struct
/pointer_to_struct.c
+/pointer_to_struct.obj
/strings
/strings.c
+/strings.obj
/type
/type.c
+/type.obj
/variable
/variable.c
+/variable.obj
/whenever
/whenever.c
+/whenever.obj
diff --git a/src/interfaces/ecpg/test/sql/.gitignore b/src/interfaces/ecpg/test/sql/.gitignore
index cd6f342..5d4fe7f 100644
--- a/src/interfaces/ecpg/test/sql/.gitignore
+++ b/src/interfaces/ecpg/test/sql/.gitignore
@@ -1,40 +1,60 @@
/array
/array.c
+/array.obj
/binary
/binary.c
+/binary.obj
/code100
/code100.c
+/code100.obj
/copystdout
/copystdout.c
+/copystdout.obj
/define
/define.c
+/define.obj
/desc
/desc.c
+/desc.obj
/describe
/describe.c
+/describe.obj
/dynalloc
/dynalloc.c
+/dynalloc.obj
/dynalloc2
/dynalloc2.c
+/dynalloc2.obj
/dyntest
/dyntest.c
+/dyntest.obj
/execute
/execute.c
+/execute.obj
/fetch
/fetch.c
+/fetch.obj
/func
/func.c
+/func.obj
/indicators
/indicators.c
+/indicators.obj
/insupd
/insupd.c
+/insupd.obj
/oldexec
/oldexec.c
+/oldexec.obj
/parser
/parser.c
+/parser.obj
/quote
/quote.c
+/quote.obj
/show
/show.c
+/show.obj
/sqlda
/sqlda.c
+/sqlda.obj
diff --git a/src/interfaces/ecpg/test/thread/.gitignore b/src/interfaces/ecpg/test/thread/.gitignore
index 12ff319..6c16f4e 100644
--- a/src/interfaces/ecpg/test/thread/.gitignore
+++ b/src/interfaces/ecpg/test/thread/.gitignore
@@ -1,10 +1,15 @@
/alloc
/alloc.c
+/alloc.obj
/descriptor
/descriptor.c
+/descriptor.obj
/prep
/prep.c
+/prep.obj
/thread
/thread.c
+/thread.obj
/thread_implicit
/thread_implicit.c
+/thread_implicit.obj
Michael Paquier wrote:
Hi all,
When running the test suite of ecpg, build generates a set of obj
files and it happens that those files are not ignored in the code
tree.
Wouldn't this be simpler as a *.obj pattern somewhere? Maybe in
ecpg/test/.gitignore add this line?
**/*.obj
--
�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
When running the test suite of ecpg, build generates a set of obj
files and it happens that those files are not ignored in the code
tree.
Applied, thanks.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at gmail dot com
VfL Borussia! For�a Bar�a! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
--
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:
Michael Paquier wrote:
When running the test suite of ecpg, build generates a set of obj
files and it happens that those files are not ignored in the code
tree.
Wouldn't this be simpler as a *.obj pattern somewhere? Maybe in
ecpg/test/.gitignore add this line?
Actually, if we are supporting toolchains that generate *.obj files,
I'd expect the top-level .gitignore to ignore them, as it does *.o.
But if that's the issue why have we not heard complaints before?
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 03/09/2015 09:46 AM, Tom Lane wrote:
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
Michael Paquier wrote:
When running the test suite of ecpg, build generates a set of obj
files and it happens that those files are not ignored in the code
tree.Wouldn't this be simpler as a *.obj pattern somewhere? Maybe in
ecpg/test/.gitignore add this line?Actually, if we are supporting toolchains that generate *.obj files,
I'd expect the top-level .gitignore to ignore them, as it does *.o.
But if that's the issue why have we not heard complaints before?
Probably because while there is lots of use on Windows there is probably
very little development.
+1 for adding a top level .gitignore entry.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Actually, if we are supporting toolchains that generate *.obj files,
I'd expect the top-level .gitignore to ignore them, as it does *.o.
But if that's the issue why have we not heard complaints before?...
+1 for adding a top level .gitignore entry.
I don't have a Windows system to test on, but how come these files were
only created in the ecpg testsuite? With the global .gitignore not
mentioning *.obj it appears those files are not created anywhere else.
Is the build process different for the rest of the tree?
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at gmail dot com
VfL Borussia! For�a Bar�a! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 03/09/2015 11:31 AM, Michael Meskes wrote:
Actually, if we are supporting toolchains that generate *.obj files,
I'd expect the top-level .gitignore to ignore them, as it does *.o.
But if that's the issue why have we not heard complaints before?...
+1 for adding a top level .gitignore entry.I don't have a Windows system to test on, but how come these files were
only created in the ecpg testsuite? With the global .gitignore not
mentioning *.obj it appears those files are not created anywhere else.
Is the build process different for the rest of the tree?
The MSVC build creates project directories which contain all the .obj
files etc. The file locations for intermediate artefacts are quite
different from the way a Unix build works. There is an ignore rule for
these directories, which covers the .obj files there. But ecpg files are
generated like in Unix builds. Since we have a global ignore rule for .o
files it makes plenty of sense to have one for .obj files also.
Certainly better than have one rule for each ecpg test case.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
On 03/09/2015 11:31 AM, Michael Meskes wrote:
I don't have a Windows system to test on, but how come these files were
only created in the ecpg testsuite? With the global .gitignore not
mentioning *.obj it appears those files are not created anywhere else.
Is the build process different for the rest of the tree?
The MSVC build creates project directories which contain all the .obj
files etc. The file locations for intermediate artefacts are quite
different from the way a Unix build works. There is an ignore rule for
these directories, which covers the .obj files there. But ecpg files are
generated like in Unix builds.
Ah. That's lots more plausible than "no one's ever done any development
on Windows". I can believe that not so many people have run the ecpg
tests there.
Since we have a global ignore rule for .o
files it makes plenty of sense to have one for .obj files also.
Certainly better than have one rule for each ecpg test case.
Agreed. So we should revert the previous patch ...
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 09.03.2015 16:58, Tom Lane wrote:
Andrew Dunstan <andrew@dunslane.net> writes:
The MSVC build creates project directories which contain all the .obj
files etc. The file locations for intermediate artefacts are quite
different from the way a Unix build works. There is an ignore rule for
these directories, which covers the .obj files there. But ecpg files are
generated like in Unix builds.Ah. That's lots more plausible than "no one's ever done any development
on Windows". I can believe that not so many people have run the ecpg
tests there.
Completely agreed.
Since we have a global ignore rule for .o
files it makes plenty of sense to have one for .obj files also.
Certainly better than have one rule for each ecpg test case.Agreed. So we should revert the previous patch ...
Done.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at gmail dot com
VfL Borussia! For�a Bar�a! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Mar 10, 2015 at 2:50 AM, Michael Meskes <meskes@postgresql.org> wrote:
On 09.03.2015 16:58, Tom Lane wrote:
Andrew Dunstan <andrew@dunslane.net> writes:
The MSVC build creates project directories which contain all the .obj
files etc. The file locations for intermediate artefacts are quite
different from the way a Unix build works. There is an ignore rule for
these directories, which covers the .obj files there. But ecpg files are
generated like in Unix builds.Ah. That's lots more plausible than "no one's ever done any development
on Windows". I can believe that not so many people have run the ecpg
tests there.Completely agreed.
Since we have a global ignore rule for .o
files it makes plenty of sense to have one for .obj files also.
Certainly better than have one rule for each ecpg test case.Agreed. So we should revert the previous patch ...
Done.
Thanks for the fix. I did it as a global rule first, until noticing
that each regression item was listed in their own separate
.gitignore..
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers