On Mon, Jan 20 2020, Andrew Hewus Fresh <[email protected]> wrote:
> On Mon, Jan 20, 2020 at 03:00:30PM -0500, Chris Bennett wrote:
>> On Mon, Jan 20, 2020 at 04:15:42PM +0100, Jeremie Courreges-Anglas wrote:
>> > On Sun, Jan 19 2020, Chris Bennett <[email protected]>
>> > wrote:
>> > > This tests perl module versions to see which is higher version.
>> > >
>> > > I have set TEST_POD and RELEASE_TESTING.
>> > >
>> > > Unless there is some objection, I will set release and author testing
>> > > in future Perl ports also. The mechanism is there. It seems worthwhile
>> > > to use it, unless this places too big a burden on bulk builds?
>> > >
>> > > Comments?
>> >
>> > It's not our job to do release and documentation testing. Please leave
>> > this out of the Makefile.
>> >
>>
>> Honestly, I picked submitting this simple port exactly to bring up that
>> question.
>>
>> What I am seeing in the ports tree, just looking at devel/p5-* are,
>> for example.
>>
>> devel/p5-Mock-Config (and several others just under devel)
>> has MAKE_ENV += RELEASE_TESTING=Yes TEST_POD=Yes
>>
>> devel/p5-YAML
>> has TEST_ENV += AUTHOR_TESTING=1
>>
>> When I submitted p5-PGObject,
>> https://marc.info/?l=openbsd-ports&m=157645754310168&w=2
>>
>> I got a response:
>>
>> This could use "MAKE_ENV=TEST_POD=yes RELEASE_TESTING=''"
>> so that tests work the same no matter the environment.
>>
>> Other than that, OK afresh1@ if someone wants to import.
>> ---------
>>
>> I don't know what to make of the RELEASE_TESTING='' part.
>
>
> This specifically *disables* release testing, no matter whether someone
> decided to set it in their local environment. It's mostly documenting
> that we are choosing not to run those tests so that in the future folks
> don't try. I usually find that if the release testing Just Works, I
> prefer to enable it.
Disclaimer: I don't do much work in perl ports land.
TEST_POD shouldn't bring additional deps and may warn about crappy
formatting, so it may be useful.
For RELEASE_TESTING, if it just works, fine. But bringing in additional
deps and cruft in the port Makefile really seems over the top. Imagine
if we did this for all ports using automake...
>> So I don't see a clear answer on what is right, wrong or ambivalent.
>> I'm going to at least do this testing myself before submitting, since
>> these are new vs updated ports.
>> But what should or shouldn't end up in the tests in the Makefile
>> I submit?
>
> There is a lot of personal preference there. My preference is to make
> the ports tree not do something different depending on the environment
> as it makes problems easier to understand.
perl.port.mk consistently uses ${SETENV} so there's no way for a user to
leak RELEASE_TESTING or TEST_POD from their environment.
>
>> > Is this library useful for other (upcoming or existing) ports?
>>
>> Yes, this is for upcoming LedgerSMB port.
>> It is in the required section of the cpanfile.
>>
>> https://github.com/ledgersmb/LedgerSMB/blob/master/cpanfile
>>
>> Thanks,
>> Chris Bennett
>>
>>
>>
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
