Date: Sun, 4 Oct 2015 14:19:36 +0300 From: Dmitry Marakasov <amdmi3@amdmi3.ru> To: Kubilay Kocak <koobs@FreeBSD.org> Cc: Sunpoet Po-Chuan Hsieh <sunpoet@FreeBSD.org>, ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Subject: Re: svn commit: r398482 - head/devel/py-greenlet Message-ID: <20151004111935.GD44712@hades.panopticon> In-Reply-To: <5610937B.1000708@FreeBSD.org> References: <201510031707.t93H7UBs008407@repo.freebsd.org> <5610937B.1000708@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* Kubilay Kocak (koobs@FreeBSD.org) wrote: > > Author: sunpoet > > Date: Sat Oct 3 17:07:29 2015 > > New Revision: 398482 > > URL: https://svnweb.freebsd.org/changeset/ports/398482 > > > > Log: > > - Convert to new test framework > > > > Modified: > > head/devel/py-greenlet/Makefile > > > > Modified: head/devel/py-greenlet/Makefile > > ============================================================================== > > --- head/devel/py-greenlet/Makefile Sat Oct 3 17:07:24 2015 (r398481) > > +++ head/devel/py-greenlet/Makefile Sat Oct 3 17:07:29 2015 (r398482) > > @@ -12,14 +12,13 @@ COMMENT= Light-weight microthreads for P > > > > LICENSE= MIT > > > > +DO_MAKE_TEST= ${PYTHON_CMD} > > This is horrible & super ugly. I agree. Using variables in such a quirky and unintended way is incomprehensible for people reading port Makefiles and tend to break easily on framework changes. > Why can't we have / isn't there a TEST_CMD variable to complement > TEST_{ARGS,DEPENDS,*} variables? I don't see a reason for this - it'll not cover all cases and it's a pain to understand. We don't have BUILD_CMD and INSTALL_CMD either. This is obvious case where do-test: should be used. > The new test framework is VERY VERY welcome, but I'm worried it needs > polishing/refinement for extensibility across the broader ports > framework *before* a large number of ports have been 'converted', > thereby cementing in an under-baked implementation and making it much > harder to change for the better. > > Another worry is that there isn't an *explicit* opt-in or toggle to > enable tests. As I've stated several times already, there's an opt-out and it's the way it should be. It's not like broken test break user or package builds, though for test-aware environments (like users runing tests or q/a poudriere) all tests should always be visible. And all failures should be taken care of. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://amdmi3.ru
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20151004111935.GD44712>