Ports 搜索

AUnit is a set of Ada packages based on the xUnit family of unit test frameworks. It is intended as a developer's tool to facilitate confident writing and evolution of Ada software. It is purposely lightweight, as one of its main goals is to make it easy to develop and run unit tests, rather than to generate artifacts for process management. The framework supports easy composition of sets of unit tests to provide flexibility in determining what tests to run for a given purpose.

This is the legacy 2.13 version of autoconf. It is explicitly for use with older software packages that are not buildable with the current autoconf. Autoconf is an extensible package of m4 macros that produce shell scripts to automatically configure software source code packages. These scripts can adapt the packages to many kinds of UNIX-like systems without manual user intervention. Autoconf creates a configuration script for a package from a template file that lists the operating system features that the package can use, in the form of m4 macro calls.

Automake is a tool for automatically generating Makefiles compliant with the GNU Coding Standards. It was inspired by the 4.4BSD make and include files, but aims to be portable and to conform to the GNU standards for Makefile variables and targets. Automake is a Perl script. The input files are called Makefile.am. The output files are called Makefile.in; They are intended for use with Autoconf. Automake requires certain things to be done in your configure.in. This package also includes the "aclocal" program. aclocal is a program to generate an 'aclocal.m4' based on the contents of 'configure.in'. It is useful as an extensible, maintainable mechanism for augmenting autoconf.

Class::Hook enables you to trace methods calls from your code to other classes. Instead of putting 'use Foo;' in your code, simply type 'use Class::Hook;'. The class Foo is unknown in your code. It will be magically caught by Class::Hook which will call Foo itself. You can see Class::Hook as a kind of relay. You can setup a subroutine to be called before any call to Foo->amethod and a subroutine to be called after the call. Your subs will receive all the information that Foo->amethod will receive, so you can trace everything between your code and Foo.

This module adds XPath-style matching to your object trees. This means that you can find nodes using an XPath-esque query with "match()" from anywhere in the tree. Also, the "xpath()" method returns a unique path to a given node which can be used as an identifier. NOTE: This module is not yet a complete XPath implementation. Over time I expect the subset of XPath supported to grow. See the SYNTAX documentation in the module POD for details on the current level of support.

This module allows to perform schema based configuration validation. The idea is to define in a schema what valid data is. This schema can be used to create a validator object that can in turn be used to make sure that some data indeed conforms to the schema. Although the primary focus is on "configuration" (for instance as provided by modules like Config::General) and, to a lesser extent, "options" (for instance as provided by modules like Getopt::Long), this module can in fact validate any data structure.

DateTime::Calendar::Hebrew is the implementation of the Hebrew calendar. Read on for more details on the Hebrew calendar. The Hebrew/Jewish calendar is a Luni-Solar calendar. Torah Law mandates that months are Lunar. The first day of a month coincides with the new moon in Jerusalem. (In ancient times, this was determined by witnesses. Read the books in the bibliography for more info). The Torah also mandates that certain holidays must occur in certain seasons. Seasons are solar, so a calendar that can work with lunar & solar events is needed.

DateTime::Format::Builder creates DateTime parsers. Many string formats of dates and times are simple and just require a basic regular expression to extract the relevant information. Builder provides a simple way to do this without writing reams of structural code. Builder provides a number of methods, most of which you'll never need, or at least rarely need. They're provided more for exposing of the module's innards to any subclasses, or for when you need to do something slightly beyond what I expected.

ExtUtils::InstallPaths tries to make install path resolution as easy as possible. When you want to install a module, it needs to figure out where to install things. The nutshell version of how this works is that default installation locations are determined from ExtUtils::Config, and they may be individually overridden by using the install_path attribute. An install_base attribute lets you specify an alternative installation root like /home/foo and prefix does something similar in a rather different (and more complicated) way. destdir lets you specify a temporary installation directory like /tmp/install in case you want to create bundled-up installable packages.

rth is a web-based tool designed to manage requirements, tests, test results, and defects throughout the application life cycle. The tool provides a structured approach to software testing and increases the visibility of the testing process by creating a common repository for all test assets including requirements, test cases, test plans, and test results. Regardless of their geographic location, rth allows testers, developers, business analysts, and managers to monitor and gauge application readiness. The tool includes modules for requirements management, test planning, test execution, defect tracking, and reporting.