moddevaid - script to interface to the Module::DevAid module


This describes version 0.24 of moddevaid.


moddevaid [--changes_file filename ] [ --commit_todo ] [ --dist_name string ] [ --gen_readme | --nogen_readme ] [ --gen_todo | --nogen_todo ] { --modules filename } [ --pod_file filename ] [ --readme_file filename ] { --scripts filename } [ --todo_file filename ] [ --version_control string ] [ --version_file filename ] [ --old_version_file filename ] command

where command is one of



Script to aid with development, by helping (and testing) auto-building of certain files, and with the steps needed in building and committing a release.

At this point this uses the darcs or svk revision systems.

Takes a project description, either through the command line options, or via a project config file. (see CONFIG FILE for more information).


--changes_file filename

Name of the Changes file to be generated. (default: Changes)


Should we commit the TODO file we generated? If true, then will attempt to do a commit on the generated TODO file. This needs to be an option because some setups need the TODO file (as well as the .todo file) to be under revision control, and others don't. (see --gen_todo) (default: false)

--dist_name string

The distribution name of the project, such as the name of the module My::Module. (required)

--gen_readme | --nogen_readme

Should we generate a README file? (see --pod_file)

--gen_todo | --nogen_todo

Should we generate a TODO file? If true, the TODO file will be generated from a .todo file of the kind created by the devtodo program. (see --todo_file)

--modules filename

The module files in the project. Must have their path relative to the top directory of the project. To add more than one, repeat the option. (required)

--old_version_file filename

The file which will hold the previous version (gets updated by VERSION command). (see --version_file) (default: old_version.txt)

--pod_file filename

The file which contains the POD from which the README file should be generated. If not defined, defaults to the first module in the modules list.

If gen_readme is true, the README file will be generated from select sections of the --pod_file file. The important ones are NAME, DESCRIPTION, INSTALLATION, REQUIRES and AUTHOR.

--readme_file filename

Name of the README file to be generated. (default: README)

--scripts filename

The script files in the project (if any). Must have their path relative to the top directory of the project. To add more than one, repeat the option.

--todo_file filename

Name of the TODO file to be generated. (default: TODO)

--version_control string

Which version-control (revision control) system is being used. The options are 'darcs' and 'svk'. The version control system is used for listing and committing changes. (default: darcs)

--version_file filename

The file from which to take the version. The version should be in the form of a standard VERSION id: number.number on a line by itself. Optionally, it can be number.number followed by a general id, for example 2.03_rc1 (default: version.txt)


The commands are:


Dump the Module::DevAid object on STDOUT and exit. Good for checking what the script thinks the settings are.


Show what the Changes file generated from the change-log would be like.


List the changes committed since the last release. (This is the same format as is used for updating the Changes file.)


Show what the README file generated from the Pod documentation in the module would be like. (prints on STDOUT)


Show what the TODO file generated from devtodo .todo file would be like.


Change version-number in designated files. Reads the new version from the version_file, so you can use this to test version-changing by simply not changing the version file, and see if things still look okay.


Do all of the above and all the other things required for a release, including commits. So only do this if you're sure that everything is okay.

When making a release do the following:

1. Check for unrecorded changes: "darcs whatsnew -s" and/or "darcs whatsnew -ls" or "svk status" and commit them.

2. Check that the tests pass: "Build test".

3. Update version.txt (can't automate this since it requires a human decision as to what the next version number is).

4. "moddevaid RELEASE"


The information about a project can be given in a config file, which defaults to 'mod_devaid.conf' in the current directory. If you want to use a different file, set the MOD_DEVAID_CONF environment variable, and the script will use that.

The options which can be set in the config file are exactly the same as those which can be set on the command line, with two additions: version_bump_code and version_bump_files.

The options are set with a 'option = value' setup. Blank lines are ignored.

For example:

	dist_name = My::Module
	modules = lib/My/ lib/My/Module/
	gen_readme = 1


Use with CAUTION.

This defines additional code which can be used for the automatic update of version numbers in files. It has to be defined all on one line, and basically be a subroutine definition, like so:

version_bump_code = sub { my $version = shift; # code to update files ... };

Reference to a function which will perform custom actions to automatically change the version-id. The default actions go through the modules and scripts and update anything matching a standard VERSION-setting string, and which matches a 'This describes version' string. This subroutine is for doing anything additional or different.

This is given one arguments, the version string.


The list of files altered by the version_bump_code, so that all the version changes can be committed at the same time. This is needed because some tests require the test files to have the version-id in them, and therefore all version commits should be done at the same time, otherwise the tests will fail, and the commits won't work.


Getopt::Long Getopt::ArgvFile Pod::Usage File::Basename Module::DevAid Data::Dumper


perl(1). Module::DevAid


    Kathryn Andersen (RUBYKAT)
    perlkat AT katspace dot com