~alpine/devel

4 4

Re: [alpine-devel] Proposal: testsuite support in APKBUILDs

Ed Robinson
Details
Message ID
<CAFH_Dguqgd5eMY4UzuqPPuX2HqcWDOsKiwu3pN3c5d0idPawEw@mail.gmail.com>
Sender timestamp
1485504619
DKIM signature
missing
Download raw message
I would prefer test over check and (testsuite). Test is a verb so fits
nicely with the other commands. "make test" is used about 4 times more
often than make check in the existing packages.
https://github.com/alpinelinux/aports/search?utf8=%E2%9C%93&q=make+test&type=Code
(634 results) vs
https://github.com/alpinelinux/aports/search?utf8=%E2%9C%93&q=make+check&type=Code
(180 results)

I think the idea is a good one overall and I think while naming is
moderately important, having the feature is more important than getting the
name right...

,Ed

On Fri, Jan 27, 2017 at 7:59 AM, 7heo <7heo@mail.com> wrote:

> I am really confused that you want to use a wrong vocab because GNU
> software already use it. Plus, it was my understanding that our tool's name
> isn't 'make' (since it's about identical terms).
>
> I understand that for many people this discussion may seems like a waste
> of time, but using the correct vocabulary is an essential part of
> code-as-documentation.
>
> Going with check is not a huge inaccuracy I admit; but it will most likely
> effectively hinder the understanding of newcomers while lowering the
> learning curve for GNU people/users.
>
> I can explain in a separate mail (or on IRC) why I think it is a bad
> enough idea to attract GNU contributors to alpine, to justify continuing
> this discussion; but I'll assume here that all alpine contributors share a
> similar view on the GNU code style.
>
> So, does anyone agree?
>
> Theo
>
> On Fri Jan 27 02:28:32 2017 GMT+0100, William Pitcock wrote:
> > Hello,
> >
> > In some ways I am inclined to agree with Jakub, mostly because "make
> > check" is the main way of invoking a testsuite on autotools platforms.
> > It is perhaps not the most correct description of the phase, but it
> > does fit with "make check" usage in autotools, so people would be
> > familiar with it.
> >
> > Lets move forward with check phase and !check in $features?
> >
> > William
> >
> > On Thu, Jan 26, 2017 at 8:34 AM, 7heo <7heo@mail.com> wrote:
> > > Hey,
> > >
> > > Since we're talking about vocabulary and semantics, I would rather
> avoid check, since it doesn't reflect what happens. A testsuite is a suite
> (set of, ordered, predictable) of tests (dynamic procedure to validate an
> element, that has to be executed). A check is merely an observation with
> assertion on an existing state. As an example, you can check the door is
> open, but you have to test if the lock works (you can't just check it in
> normal conditions and without a specialized apparatus).
> > >
> > > Long story short, I don't have any problem with making it shorter and
> simpler, but I would rather have something that matches what is actually
> does. :)
> > >
> > > Theo.
> > >
> > > On Thu Jan 26 14:08:29 2017 GMT+0100, Jakub Jirutka wrote:
> > >> Hi,
> > >>
> > >> currently we have the following phases: sanitycheck, builddeps,
> clean, fetch, unpack, prepare, mkusers, rootpkg, cleanup. All of them
> except rootpkg are verbs. So I’d prefer “check” (as Arch) instead of
> “testsuite”.
> > >>
> > >> Jakub
> > >>
> > >> > On 26. Jan 2017, at 10:26, Timo Teras <timo.teras@iki.fi> wrote:
> > >> >
> > >> > On Wed, 25 Jan 2017 21:38:00 -0600
> > >> > William Pitcock <nenolod@dereferenced.org> wrote:
> > >> >
> > >> >> As such, I propose we add a testsuite() phase to the build process,
> > >> >> that runs after build(), but prior to package().  APKBUILDs should
> > >> >> override the testsuite phase, but the default_testsuite() function
> > >> >> will be a noop for the Alpine 3.6 release cycle that raises a
> warning
> > >> >> that the APKBUILD does not define any mechanism for running a
> > >> >> testsuite.  If "!testsuite" is defined in $features, the warning is
> > >> >> ignored.
> > >> >>
> > >> >> For cross-builds, the testsuite would be skipped unless the package
> > >> >> is noarch.
> > >> >>
> > >> >> After Alpine 3.6 (or maybe 3.7), we change the warning to a fatal
> > >> >> error, requiring APKBUILDs to explicitly opt out of running a
> > >> >> testsuite through $features.
> > >> >>
> > >> >> Thoughts?
> > >> >
> > >> > +1
> > >> >
> > >> > We have some packages that run 'make check' or similar, but it
> would be
> > >> > good to make it a separate step.
> > >> >
> > >> > The above plan sounds good to me.
> > >> >
> > >> > Thanks,
> > >> > Timo
> > >> >
> > >> >
> > >> > ---
> > >> > Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
> > >> > Help:         alpine-devel+help@lists.alpinelinux.org
> > >> > ---
> > >> >
> > >>
> > >>
> > >>
> > >> ---
> > >> Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
> > >> Help:         alpine-devel+help@lists.alpinelinux.org
> > >> ---
> > >>
> > >>
> >
>

Re: [alpine-devel] Proposal: testsuite support in APKBUILDs

7heo
Details
Message ID
<5lc9bo.okfksl.1hge16s-qmf@gmx.com>
In-Reply-To
<20170127101502.7a2ff893@vostro.util.wtbts.net> (view parent)
Sender timestamp
1485507330
DKIM signature
missing
Download raw message
What about 'tests' or 'runtests'?

But I agree with Ed that getting the feature is much more important than getting the name right.

Theo.

On Fri Jan 27 09:15:02 2017 GMT+0100, Timo Teras wrote:
> On Fri, 27 Jan 2017 08:10:19 +0000
> Ed Robinson <ed.robinson@reevoo.com> wrote:
> 
> > I would prefer test over check and (testsuite). Test is a verb so fits
> > nicely with the other commands. "make test" is used about 4 times more
> > often than make check in the existing packages.
> > https://github.com/alpinelinux/aports/search?utf8=%E2%9C%93&q=make+test&type=Code
> > (634 results) vs
> > https://github.com/alpinelinux/aports/search?utf8=%E2%9C%93&q=make+check&type=Code
> > (180 results)
> > 
> > I think the idea is a good one overall and I think while naming is
> > moderately important, having the feature is more important than
> > getting the name right...
> 
> 'test' is a shell built-in and due to the way abuild is implemented, it
> cannot be used. It would break lots of stuff.
> 
> I have no strong opinion over 'check' or 'testsuite'.
> 
> I'm planning to add 'rootbld' that will do a clean chroot build of the
> package. So that would not be strictly a verb either. I have patch for
> this, but it's pending a way to configure the repository URLs properly.
> 
> /Timo
>

Re: [alpine-devel] Proposal: testsuite support in APKBUILDs

Timo Teras
Details
Message ID
<20170127101502.7a2ff893@vostro.util.wtbts.net>
In-Reply-To
<CAFH_Dguqgd5eMY4UzuqPPuX2HqcWDOsKiwu3pN3c5d0idPawEw@mail.gmail.com> (view parent)
Sender timestamp
1485504902
DKIM signature
missing
Download raw message
On Fri, 27 Jan 2017 08:10:19 +0000
Ed Robinson <ed.robinson@reevoo.com> wrote:

> I would prefer test over check and (testsuite). Test is a verb so fits
> nicely with the other commands. "make test" is used about 4 times more
> often than make check in the existing packages.
> https://github.com/alpinelinux/aports/search?utf8=%E2%9C%93&q=make+test&type=Code
> (634 results) vs
> https://github.com/alpinelinux/aports/search?utf8=%E2%9C%93&q=make+check&type=Code
> (180 results)
> 
> I think the idea is a good one overall and I think while naming is
> moderately important, having the feature is more important than
> getting the name right...

'test' is a shell built-in and due to the way abuild is implemented, it
cannot be used. It would break lots of stuff.

I have no strong opinion over 'check' or 'testsuite'.

I'm planning to add 'rootbld' that will do a clean chroot build of the
package. So that would not be strictly a verb either. I have patch for
this, but it's pending a way to configure the repository URLs properly.

/Timo


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

Re: [alpine-devel] Proposal: testsuite support in APKBUILDs

Leonardo Arena
Details
Message ID
<1485510316.11710.89.camel@gmail.com>
In-Reply-To
<5lc9bo.okfksl.1hge16s-qmf@gmx.com> (view parent)
Sender timestamp
1485510316
DKIM signature
missing
Download raw message
On ven, 2017-01-27 at 08:55 +0000, 7heo wrote:
> What about 'tests' or 'runtests'?
> 

Let's throw one more to the mix: "validate" ?

> But I agree with Ed that getting the feature is much more important
> than getting the name right.
> 

+1

-|_eo

Re: [alpine-devel] Proposal: testsuite support in APKBUILDs

scsijon
Details
Message ID
<e2cd8628-6ffa-cac2-81c4-310cb6489689@lamiaworks.com.au>
In-Reply-To
<1485510316.11710.89.camel@gmail.com> (view parent)
Sender timestamp
1485523356
DKIM signature
missing
Download raw message
the 'tests' switch (--tests) is what is used inside quite a number of 
packages for their internal building test steps so i wonder if that's 
appropriate and even then it may have different purposes. Maybe using it 
would get the builder/compiler confused if a problem ocurrs?

The real thing to think about before you give it a name is ?what do you 
actually want tested and how is it to proceed in yes|maybe|no 
situations. Is it a step in a package build, a step in checking for the 
overall release, or something else? Can someone outline what is to go 
where in the overall schema and what type of tests are likely to be 
actually needed please.

And Leonardo, validate is used internally in some packages for things 
like an internal crc of a code area or test against a corrupted or 
incorrect source file (usually minor code fixes at the third identity 
level being added but not altering the overall package name as it only 
uses two levels of version identity externally) so as much as I like it 
the best of what's been suggested so far I'm not sure it's appropriate 
or available, sorry.

On 01/27/2017 08:45 PM, Leonardo Arena wrote:
> On ven, 2017-01-27 at 08:55 +0000, 7heo wrote:
>> What about 'tests' or 'runtests'?
>>
>
> Let's throw one more to the mix: "validate" ?
>
>> But I agree with Ed that getting the feature is much more important
>> than getting the name right.
>>
>
> +1
>
> -|_eo
>


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---