lcfg-skeleton - Tool for creating new LCFG software projects


This documentation refers to lcfg-skeleton version 0.5.0


       $ lcfg-skeleton
       Name of the project: foo
       Is this an LCFG component? (yes/no) [yes]: 
       Short description of the project [The LCFG foo component]: 
       Name of the author [Stephen Quinney]: 
       Email address for the author []: 
       Language for component (perl/shell) [perl]: 
       Revision Control System (CVS/None) [CVS]: None
       Supported platforms [ScientificLinux5]: 
       Distribution license [GPLv2]: 
       Restart component on RPM update (yes/no) [yes]: 
       Use the CMake build system (yes/no) [yes]: 
       Check all changes are committed before a release? (yes/no) [yes]: 
       Generate the ChangeLog from the Revision-Control log? (yes/no) [yes]: 

Hitting RETURN will use the default value shown in []. The responses to the question are normally stored in the file ~/.lcfg/skeleton/defaults.yml (the location is configurable) and will be used as the defaults next time the command is run.

Alternatively it is possible to pass in parameters from the command-line and those values will be used as the defaults. You can also run in a completely non-interactive mode where the defaults are automatically accepted, you only need to specify the project name on the command line. For example:

       lcfg-skeleton --name=foo --no-lcfg --no-gencmake \
                     --rcs=CVS --no-interactive


The lcfg-skeleton script prompts the user for basic information and creates a set of skeleton files as a starting point for writing a new LCFG component.

Although this tool has been written primarily to aid in the generation of LCFG component projects it is generally useful. It can be used for any source code where you wish to use the LCFG software release tools.


There are no required arguments for this command.


Note that boolean values should be specified on the command-line like --foo or --no-foo. At the interactive user query interface they should be specified as "yes" or "no".

For convenience, on the command-line is is possible to use the shortest unique name for each option.


The name of the project. Note that in the case of an LCFG component this should be foo NOT lcfg-foo.


A short description of the project. If this is an LCFG component the default value suggested to the user is "The LCFG $name component".


The name of the author (i.e you!). The default is the string stored in the GECOS field of the passwd entry.


The email address for the author. The default is built from the current username and domain name.


This is a boolean value which controls whether the generated project is an LCFG component.


The language which will be used, this is either "perl" or "shell". This only really has an affect if you are creating an LCFG component.


Which revision-control system you intend to use for the project. Currently only "CVS" and "None" are supported. You will need the relevant LCFG::Build::VCS helper module installed for this to work.


The comma-separate list of platforms which are supported by this code (e.g. ScientificLinux5).


The license under which the source code can be distributed. This defaults to "GPLv2".


This controls whether, if this is an LCFG component, should it be restarted after package upgrade if the component is already running. This is a yes/no answer and it defaults to "yes" (it is handled in the same way as a boolean value on the command line).


This is a boolean value which controls whether the LCFG CMake infrastructure will be used to build the project.


This is a boolean value which controls whether or not to generate the project changelog from the revision-control commit logs.


This is a boolean value which controls whether the revision-control tools should check that all files are committed before making a new release.


This is a boolean value which controls whether the query_user() method will actually interact with the user or just store the values taken from the defaults file and any commandline options. This is a boolean value which defaults to false (zero).


This is a boolean value which controls whether an existing project directory will be removed if the name matches that required for the new skeleton project. This is a boolean value which defaults to false (zero).


This is the configuration file which is used to store the defaults between calls to the lcfg-skeleton tool. Normally you should not need to modify this and it defaults to ~/.lcfg/skeleton/defaults.yml.


This is the directory into which local versions of templates should be placed. Normally you should not need to modify this and it defaults to ~/.lcfg/skeleton/templates/. For reference, the standard templates are normally stored in /usr/share/lcfgbuild/templates.


If the new component is to be added automatically to the CVS, then the CVSROOT and CVS_RSH must be set correctly before running lcfg-skeleton.

By default the script assumes that the standard template directory is /usr/share/lcfgbuild/templates. You can override this using the LCFG_BUILD_TMPLDIR environment variable. If you have done a local (i.e. non-root) install of this module then this will almost certainly be necessary.

It is possible to override any of the standard templates used to generate the skeleton project by placing your own version into the directory referred to in the tmpldir attribute. This is normally ~/.lcfg/skeleton/templates/ but that can be overridden by the user.


After successfully generating a new project this command will exit with code zero. An error will result in a non-zero error code.


This script uses LCFG::Build::Skeleton which is Moose powered. That module also requires MooseX::Getopt for command-line option handling. This module is part of the LCFG build tools suite and as such requires LCFG::Build::Pkgspec and LCFG::Build::VCS. It uses the perl Template Toolkit to generate new projects. The defaults file is parsed and stored using YAML::Syck. You will also need the List::MoreUtils and UNIVERSAL::require modules.


LCFG::Build::Tools, lcfg-reltool(1)


This is the list of platforms on which we have tested this software. We expect this software to work on any Unix-like platform which is supported by Perl.

ScientificLinux6, EnterpriseLinux7, MacOSX


There are no known bugs in this application. Please report any problems to, feedback and patches are also always very welcome.


Stephen Quinney <>


Copyright (C) 2008 University of Edinburgh. All rights reserved

This library is free software; you can redistribute it and/or modify it under the terms of the GPL, version 2 or later.