Обсуждение: automating perl compile time checking
Here is a follow up patch to last weeks commit allowing all perl files to be checked clean for compile time errors and warnings. 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. The directory pgperlcritic is renamed to perlcheck, as it not contains the new script as well as pgperlcritic. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Вложения
> 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 filethat is sourced by the three locations that need it. +1 on centralizing the find-files function. > The directory pgperlcritic is renamed to perlcheck, as it not contains the new script as well as pgperlcritic. This comment should say “perlcheck/..” and not “pgperlcritic/.." I assume: --- /dev/null +++ b/src/tools/perlcheck/pgperlcritic @@ -0,0 +1,20 @@ +#!/bin/sh + +# src/tools/pgperlcritic/pgperlcritic cheers ./daniel
On 06/05/2018 05:14 PM, Daniel Gustafsson wrote: > > This comment should say “perlcheck/..” and not “pgperlcritic/.." I assume: > Thanks. will fix. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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 singlefile 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. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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 singlefile 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. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 6/11/18 15:38, Andrew Dunstan 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 singlefile 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. Why is this being committed after feature freeze? -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 06/11/2018 04:01 PM, Peter Eisentraut wrote: > On 6/11/18 15:38, Andrew Dunstan 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 singlefile 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. > Why is this being committed after feature freeze? > This affects pretty much nothing. In fact some of the other changes I've recently committed were arguably more dangerous. Do you want me to revert the whole lot? cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> On 06/11/2018 04:01 PM, Peter Eisentraut wrote:
>> Why is this being committed after feature freeze?
> This affects pretty much nothing. In fact some of the other changes I've
> recently committed were arguably more dangerous. Do you want me to
> revert the whole lot?
AFAICS this is adding testing, not "features", so it seems fine from here.
regards, tom lane
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
On 6/11/18 16:06, Andrew Dunstan wrote: > This affects pretty much nothing. In fact some of the other changes I've > recently committed were arguably more dangerous. Do you want me to > revert the whole lot? No, but this whole let's clean up the Perl code initiative seemed to have come out of nowhere after feature freeze. The Perl code was fine before, so if we're going to be polishing it around it should go into the next release. I would actually have liked to have had more time to discuss some of the changes, since I didn't seem to agree to some of them at first reading. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On 06/15/2018 12:21 AM, Peter Eisentraut wrote: > On 6/11/18 16:06, Andrew Dunstan wrote: >> This affects pretty much nothing. In fact some of the other changes I've >> recently committed were arguably more dangerous. Do you want me to >> revert the whole lot? > No, but this whole let's clean up the Perl code initiative seemed to > have come out of nowhere after feature freeze. The Perl code was fine > before, so if we're going to be polishing it around it should go into > the next release. I would actually have liked to have had more time to > discuss some of the changes, since I didn't seem to agree to some of > them at first reading. > There were changes made for perlcritic, but almost none for this check. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services