Is there a document on how to use/implement this target? I was trying
to test devel/libffi and noted that the target doesn't work.
sean
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe,
I'm trying to add regression tests to my port.
The tests can be run with various levels of
verbosity of output. I'd like to let the
user to choose the verbosity for tests.
At present I've this:
regression-test check test: build
@${ECHO_CMD} Testing static SLATEC library
At the moment, many ported applications/libraries provide some form of
regression testing, but very few ports actually expose this via the
standard regression-test target. The regression-test target will be
called by tinderbox if available, and should also make debugging
misbehaving ports
Hi guys,
Can we please change regression-test targets to full-regression-test
(like 1 of the gcc ports did)
I really don't need to spend 1 hour for tcl, 10 minutes for perl
and 30 minutes for gcc.
I doubt pointyhat does either.
thx
email as asked by linimon from #bsdports
tests found bugs, which
is the entire point.
In my experience from OpenBSD, where make regress has been a
standard part of the bsd.port.mk framework for a long time, a failing
regression test is not infrequently a problem in the test itself
rather than in the tested functionality.
I do agree
Le Ven 20 jui 08 à 3:54:04 +0200, Garrett Cooper [EMAIL PROTECTED]
écrivait :
I try to enable regression-test when possible, but the current
implementation is a post-build target, and some ports' testings need a
post-install target. In these cases, I enclose the regression-test
target
Thierry Thomas wrote:
Le Ven 20 jui 08 à 3:54:04 +0200, Garrett Cooper [EMAIL PROTECTED]
écrivait :
I try to enable regression-test when possible, but the current
implementation is a post-build target, and some ports' testings need a
post-install target. In these cases, I enclose
in
circumstances as close as possible to those in which
it will be used -- i.e., after it's been installed.
But pragmatically, it really comes down to the tests
that will be implemented. If this regression-test
target is largely there to allow bundled testing
targets to be run from the port Makefile
.
FWIW, I started adding those regression-test targets to many ports
because they are extremely useful: while trying to update to the
latest coreutils I found everything apparently built but everything
was actually broken. Now I am finding bugs in some ports that I
thought were fine.
Which
would be excessive.
FWIW, I started adding those regression-test targets to many ports
because they are extremely useful: while trying to update to the
latest coreutils I found everything apparently built but everything
was actually broken. Now I am finding bugs in some ports that I
thought were fine
On Thu, Jun 19, 2008 at 12:35:01PM -0400, Wesley Shields wrote:
Which is why I would recommend wrapping them in checks for
MAINTAINER_MODE or something similar. This way you, as the maintainer,
can turn them on when you want but they don't affect anything else.
That's true for the OS versions
--- Gio 19/6/08, Wesley Shields [EMAIL PROTECTED] ha scritto:
...
Which is why I would recommend wrapping them in checks for
MAINTAINER_MODE or something similar. This way you, as the
maintainer,
can turn them on when you want but they don't affect
anything else.
Good reasons NOT to
Tom Hukins wrote:
On Thu, Jun 19, 2008 at 12:35:01PM -0400, Wesley Shields wrote:
Which is why I would recommend wrapping them in checks for
MAINTAINER_MODE or something similar. This way you, as the maintainer,
can turn them on when you want but they don't affect anything else.
That's true
a favour :-)
I try to enable regression-test when possible, but the current
implementation is a post-build target, and some ports' testings need a
post-install target. In these cases, I enclose the regression-test
target between .ifdef MAINTAINER_MODE.
--
Th. Thomas
you're doing
us a favour :-)
I try to enable regression-test when possible, but the current
implementation is a post-build target, and some ports' testings need a
post-install target. In these cases, I enclose the regression-test
target between .ifdef MAINTAINER_MODE.
I'd say those ports
So I just learned that pointyhat tries to run a target regression-test
as part of the build. (Somebody asked me to use that target in a
port.)
Is this documented somewhere?
In particular, running tests of what duration would be considered
appropriate? E.g., building audio/flac takes a minute
On Wed, Jun 18, 2008 at 05:08:54PM +, Christian Weisgerber wrote:
So I just learned that pointyhat tries to run a target regression-test
as part of the build. (Somebody asked me to use that target in a
port.)
Is this documented somewhere?
Not anywhere I know of, and it may be something
Christian Weisgerber wrote:
So I just learned that pointyhat tries to run a target regression-test
as part of the build. (Somebody asked me to use that target in a
port.)
Is this documented somewhere?
I don't know off-hand. I assume you searched the handbook?
In particular, running tests
Kris Kennaway:
Is this documented somewhere?
I don't know off-hand. I assume you searched the handbook?
There is no mention of it in the Porter's Handbook and a cursory
Google search only turned up build logs, commit messages, and the
like.
--
Christian naddy Weisgerber
19 matches
Mail list logo
