Re: automating perl compile time checking
От | Andrew Dunstan |
---|---|
Тема | Re: automating perl compile time checking |
Дата | |
Msg-id | ea096bb5-f1cb-2999-494a-5932f660f5ff@2ndQuadrant.com обсуждение исходный текст |
Ответ на | Re: automating perl compile time checking (Andrew Dunstan <andrew.dunstan@2ndquadrant.com>) |
Список | pgsql-hackers |
On 06/11/2018 03:38 PM, Andrew Dunstan wrote: > > > On 06/11/2018 02:33 PM, Alvaro Herrera wrote: >> On 2018-Jun-05, Daniel Gustafsson wrote: >> >>>> On 5 Jun 2018, at 16:31, Andrew Dunstan >>>> <andrew.dunstan@2ndquadrant.com> wrote: >>>> The patch contains a simple script to run the checks. The code that >>>> finds perl files is put in a function in a single file that is >>>> sourced by the three locations that need it. >>> +1 on centralizing the find-files function. >> +1 on that. Why do we need to make the new find_perl_files file >> executable, given it's always sourced? (I would have given a .sh >> extension because it's a lib not an executable, but I suppose that's >> just matter of taste; we certainly don't have a policy about it). >> >> Looks fine to me either way. >> > > > I've committed this, but I'm fine if people want to tweak the names. > It probably doesn't need to be executable. > > People might be interested to see the perlcritic and 'perl -cw" checks in operation: https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=crake&dt=2018-06-11%2021%3A47%3A18&stg=perl-check The module isn't actually using the scripts in src/tools/perlcheck, because they are designed to be quiet and it's designed to be more verbose, but apart from that it's doing exactly the same thing. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: