Downsides of scanning all .o files for typedefs
I'd been getting weird results for the last couple of days while
pgindent-ing various patches. I eventually realized that the cause
was that the current typedefs list marks "c", "string", and a few
other common words as typedefs. This seems pretty uncool. Further
investigation shows that the reason is that these names are used as
typedefs in a couple of the ecpg regression tests; which the old
find_typedefs code never picked up on, but the OS X implementation
does.
Now, it's actually rather pointless to collect typedef names from
the ecpg tests, since pgindent won't process files with .pgc
extensions anyway (and I doubt it would work well to try).
So we could either revise these test cases to use less-generic
typedef names, or we could just skip ecpg/test/ in find_typedefs.
For the moment I've got dromedary using the attached quick-hack patch
to do the latter. Any thoughts on the best long-term answer?
regards, tom lane
Attachments:
dont-find-typedefs-in-ecpg-tests.patchtext/x-diff; charset=us-ascii; name=dont-find-typedefs-in-ecpg-tests.patchDownload
diff -c build-farm-4.12.orig/run_build.pl build-farm-4.12/run_build.pl
*** build-farm-4.12.orig/run_build.pl Sat Apr 5 17:15:45 2014
--- build-farm-4.12/run_build.pl Sat Apr 5 23:13:37 2014
***************
*** 1533,1540 ****
{
# On OS X, we need to examine the .o files
my $obj_wanted = sub {
! /^.*\.o\z/s && push(@testfiles, $File::Find::name);
};
File::Find::find($obj_wanted,$pgsql);
--- 1533,1541 ----
{
# On OS X, we need to examine the .o files
+ # exclude ecpg/test, which pgindent does too
my $obj_wanted = sub {
! /^.*\.o\z/s && ! ($File::Find::name =~ m!/ecpg/test/!s) && push(@testfiles, $File::Find::name);
};
File::Find::find($obj_wanted,$pgsql);
On 04/06/2014 12:06 PM, Tom Lane wrote:
I'd been getting weird results for the last couple of days while
pgindent-ing various patches. I eventually realized that the cause
was that the current typedefs list marks "c", "string", and a few
other common words as typedefs. This seems pretty uncool. Further
investigation shows that the reason is that these names are used as
typedefs in a couple of the ecpg regression tests; which the old
find_typedefs code never picked up on, but the OS X implementation
does.Now, it's actually rather pointless to collect typedef names from
the ecpg tests, since pgindent won't process files with .pgc
extensions anyway (and I doubt it would work well to try).So we could either revise these test cases to use less-generic
typedef names, or we could just skip ecpg/test/ in find_typedefs.
For the moment I've got dromedary using the attached quick-hack patch
to do the latter. Any thoughts on the best long-term answer?
As you say we're not going to be indenting the .pgc files anyway, so
this seems like quite a reasonable solution.
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