The tack script runs ack from repository root using the module files placed under blib/lib via
the build process. It's a quick and easy way to try out new code, or to check some debugging
output. Since it relies on the module files under blib/lib, make sure you run make before
running tack!
This script is built by the make ack-standalone rule, and is a single file distribution of ack.
The make ack-standalone rule uses the squash script to perform the actual building.
Takes a list of Perl source files and builds a single Perl script containing all of the input files.
Times ack in a number of common scenarios. We currently use a checkout of the Parrot repository
for testing, as it's a medium sized codebase. dev/timings.pl expects a checkout of the Parrot
repository in your $HOME directory. See dev/timings.pl --help for more information on its
options.
The test suite can build what we call an "option coverage" file if the ACK_OPTION_COVERAGE
environment variable is set to a truthy value. The option coverage file lists all of the options
provided to the various options provided to the various invocations of ack used in the test suite.
dev/display-options-coverage.pl reads this file and prints the options that are not used in
the test suite. This helps find new options that haven't had tests written for them yet.
Runs ack through Devel::NYTProf.
Shorthand for dev/timings.pl.
Runs the make test_classic and make test_standalone rules.
Runs the test suite using the module files in the repository.
Runs the test suite using the ack-standalone script.
Can be used to run individual test files. This relies on the module files being
placed under blib/lib, so be sure to run make before running prove!
ack's test suite captures standard output and standard error, so writing debug messages
to standard error will show up in the captured output, and cause the test suite to fail.
We have an App::Ack::Debug module for emitting test-safe debugging output, but it doesn't
get placed under blib by default.
Development is not done on master. We use a dev branch named
dev, and from there topic branches named for a specific topic.
master -> dev -> docs
\-> speedups
\-> issue473
The only time we merge dev down to master is when doing a
release. There are no branches off of master other than dev.
Our policy on commits is that they're cheap; we tend to throw files into the repository that could prove useful to others, even if we will remove them later.
We have a perlcriticrc and a perltidyrc file for checking the Perl source files.
These can be done by anyone, except for the upload to CPAN.
- Prep all source files for release.
- If this is a final release, replace all
2.XX_01version numbers with2.YY, where XX is odd and YY is even. - Update the
Changesfile with the new version numbers and put a date in the header.
- If this is a final release, replace all
make cleanandmake testrepeatedly.make disttest- Should pass.
make tardist- Creates a tarball
- Upload the tarball to pause.cpan.org
- Tag the release
git tag 2.XXgit push --tags
Do all of the above for a development release, plus:
- Put a version of standalone into the garage.
- Update beyondgrep.com
- https://github.com/petdance/beyondgrep
- Front page version number
- man page archive
- Announce it
- Mail to ack-users and ack-announce.
- Post to ack's Google+ page.
- Tweet on @beyondgrep.
TODO
Our issues are hosted on GitHub.
TODO
Issues with this milestone should be resolved on the dev branch. These
are usually bug fixes.
XXX I want to not call this "2.1" because it conflates with "2.10" which is coming soon. Let's give it some easy-to-type textual name, like "goober" or "lemon" or who knows what.
Issues with this milestone should be resolved on the 2.1-work branch. These
are usually new features.
Issues with this milestone are either questionable features, or features that are too far out to schedule on another milestone.
I know how you feel! But any contribution is welcome; you don't need to be a full-time contributor. Every test file, every issue solved, every bug fixed matters!
That's ok; it's easy to learn! Perl may have a reputation for being unreadable, but ack is written in a very easy-to-read style.
TODO Mention http://perl-begin.org/
TODO
This is the main entry point for ack. It contains a great deal of the code, as well as the POD documentation that is used to generate man pages.
This contains the App::Ack package, which stores more of the general "helper" code
for ack. Chances are that if you want to change something, it'll be in Ack.pm
or ack.
An abstract superclass that represents a searchable "resource" (usually a file on a filesystem).
A factory object for creating a stream of Resource objects.
An abstract superclass that represents objects that can filter Resource objects.
Implements a basic (on-filesystem) Resource object.
A module that contains the default configuration for ack.
A module that contains the logic for locating the various configuration files.
A module that contains the logic for loading configuration files.
Contains a single routine for printing to the console while being run in the test suite.
The class that implements the filter that ack uses by default if you don't specify any filters on the command line.
The class that implements filtering resources by file extension.
The class that implements filtering resources by their first line.
The class that inverts another filter.
The class that implements filtering resources by their filename (exact match).
The class that implements filtering resources by their filename (regular expression).
TODO