cpet/openbsd-ports
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
2314c85f45
openbsd-ports/databases/p5-DBD-Mock/Makefile

25 lines
449 B
Makefile
Raw Normal View History

convert to new style depends zap default spec that are not needed convert libspecs as well convert p* to REVISION. No package changes
2010-11-14 19:22:45 -05:00
# $OpenBSD: Makefile,v 1.4 2010/11/15 00:22:52 espie Exp $
import p5-DBD-Mock Testing with databases can be tricky. If you are developing a system married to a single database then you can make some assumptions about your environment and ask the user to provide relevant connection information. But if you need to test a framework that uses DBI, particularly a framework that uses different types of persistence schemes, then it may be more useful to simply verify what the framework is trying to do -- ensure the right SQL is generated and that the correct parameters are bound. DBD::Mock makes it easy to just modify your configuration (presumably held outside your code) and just use it instead of DBD::Foo (like DBD::Pg or DBD::mysql) in your framework. ok sthen@
2007-11-22 14:43:34 -05:00
COMMENT= mock database driver for testing
MODULES= cpan
update to version 1.37
2008-07-27 18:42:41 -04:00
DISTNAME= DBD-Mock-1.37
import p5-DBD-Mock Testing with databases can be tricky. If you are developing a system married to a single database then you can make some assumptions about your environment and ask the user to provide relevant connection information. But if you need to test a framework that uses DBI, particularly a framework that uses different types of persistence schemes, then it may be more useful to simply verify what the framework is trying to do -- ensure the right SQL is generated and that the correct parameters are bound. DBD::Mock makes it easy to just modify your configuration (presumably held outside your code) and just use it instead of DBD::Foo (like DBD::Pg or DBD::mysql) in your framework. ok sthen@
2007-11-22 14:43:34 -05:00
CATEGORIES= databases devel
USE_GROFF=Yes
2010-10-18 13:06:05 -04:00
USE_GROFF = Yes
import p5-DBD-Mock Testing with databases can be tricky. If you are developing a system married to a single database then you can make some assumptions about your environment and ask the user to provide relevant connection information. But if you need to test a framework that uses DBI, particularly a framework that uses different types of persistence schemes, then it may be more useful to simply verify what the framework is trying to do -- ensure the right SQL is generated and that the correct parameters are bound. DBD::Mock makes it easy to just modify your configuration (presumably held outside your code) and just use it instead of DBD::Foo (like DBD::Pg or DBD::mysql) in your framework. ok sthen@
2007-11-22 14:43:34 -05:00
MAINTAINER= Simon Bertrang <simon@openbsd.org>
# Perl
PERMIT_PACKAGE_CDROM= Yes
PERMIT_PACKAGE_FTP= Yes
PERMIT_DISTFILES_CDROM= Yes
PERMIT_DISTFILES_FTP= Yes
convert to new style depends zap default spec that are not needed convert libspecs as well convert p* to REVISION. No package changes
2010-11-14 19:22:45 -05:00
RUN_DEPENDS= databases/p5-DBI
import p5-DBD-Mock Testing with databases can be tricky. If you are developing a system married to a single database then you can make some assumptions about your environment and ask the user to provide relevant connection information. But if you need to test a framework that uses DBI, particularly a framework that uses different types of persistence schemes, then it may be more useful to simply verify what the framework is trying to do -- ensure the right SQL is generated and that the correct parameters are bound. DBD::Mock makes it easy to just modify your configuration (presumably held outside your code) and just use it instead of DBD::Foo (like DBD::Pg or DBD::mysql) in your framework. ok sthen@
2007-11-22 14:43:34 -05:00
CONFIGURE_STYLE=modbuild
MAKE_ENV+= TEST_POD=1
.include <bsd.port.mk>
Reference in New Issue Copy Permalink