Clone

HTTPS: git clone https://vervis.peers.community/repos/yEzqv

SSH: git clone USERNAME@vervis.peers.community:yEzqv

Branches

master

name-template.mdwn

The project skeletons will use specific strings as the project name. Each such string has an exact rule determining how it is converted into the name of the actual project made from the skeleton. Then the strings may be replaced using regex substitution.

The general name of the project is ‘ProgramSkeleton’ for a program and ‘libSkeleton’ for a library. All other forms of the name used in the skeletons are derived from these.

Forms of the name:

NiceCase, niceCase: This is the human friendly representation, not intended for any computation
UPPERCASE: Nicecase with all letters converted to uppercase
MACRO_CASE: Nicecase with letters converted to uppercase, and with each uppercase letter in Nicecase preceded by a lowercase letter prepended with an underscore
lowercase: Nicecase with all letters converted to lowercase
var_case: Nicecase with letters converted to lowercase, and with each uppercase letter in Nicecase preceded by a lowercase letter prepended with an underscore

These forms don’t need to take the ‘lib’ prefix into account: Many libraries don’t have it, and don’t have to. Nothing should depend on the presence of the prefix.

These forms will be generated for the project skeletons and pasted into their code. When the user chooses a specific project name for use with a skeleton, these forms are generated for that name as well, and then each form in the files is substituted with the form generated from the name chosen by the user. The NiceCase form is the chosen name, and the other forms are generated from it.

Here are examples for ProgramSkeleton and libSkeleton:

Nicecase: ProgramSkeleTon
- Uppercase: PROGRAMSKELETON
- Macrocase: PROGRAM_SKELETON
- Lowercase: programskeleton
- Varcase: program_skeleton
Nicecase: libSkeleton
- Uppercase: LIBSKELETON
- Macrocase: LIB_SKELETON
- Lowercase: libskeleton
- Varcase: lib_skeleton

For the names in the skeletons, all forms must be different. For the name chosen by the user, it is fine for forms to be identical.

Additional Name-Derived Strings

The name of the project may be used in other names as well, which don’t necessarily match any of the forms in the list. These forms require additional entries in the substitution table.

Namespace

For C++, the top-level namespace is usually based on the project name but there is no convention for setting it. For example, for a project name GSTC it may be GSTC or Gstc or gstc or even something else. Therefore, the namespace should be set separately. It is possible to not have one at all, of course.

The template is SkeletonSpace, for both the C++ program skeleton and C++ library skeleton.

Description

This is a one-line description of the project. I’m adding this because I want the description in the pkg-config file of libSkeleton to have the description field automatically replaced with the user’s input. But I may decide to use it in other places as well, or even define it inside the Autotools files for global access.

The template for libSkeleton is: “A C++ library skeleton using Autotools”.

Stripped Library Name

In the pkg-config file there is usage of a stripped version of the library name. When passing -l flags to the compiler/linker, a library whose name begins with ‘lib’ gets the ‘lib’ stripped, therefore the stripped version must be used.

Basically, if lowercase version of the name starts with ‘lib’, strip it. But I need to check exactly when the ‘lib’ is stripped, e.g. does “lib-something” get stripped to “-something”? Check in the GNU manuals etc. [[TODO|TODO/OPEN]]

[See repo JSON]