zproject(part1): getting started

ZProject is a project skeleton generator that helps you create c-APIs and generate multiple build-targets(cmake,autotools,..) with multiple scripting-language-bindings(python,lua,...) . The single source of truth is that project.xml-File that controls what flows will run. The whole workflow is based on the GSL-Templating/Scripting-Tool.

Disclaimer: I just started using ZProject and wasn't a c-programmer or the CLASS-paradigm enforced by this project.

In order to start using ZProject follow the instructions after which you should have ZProject and GSL installed.

getting started

Create a minimal project.xml:

<project script = "zproject.gsl" 
         name ="gs">
    <version major = "1" minor = "1" patch = "0" />
    <class name = "shouter"/>
    <main name = "starter" private = "1" />
</project>

The <project/>-tag encapsulates all that for your project. It has multiple attributes, but the most important (for any gsl-template) is:

• The script-attribute which defines what script should process the data we are defining in this xml. In this case it is zproject.gsl which gets installed when you install ZProject.
• The name-attribute defines the name of the library. In this case if we generate the project and build it, we would get a lib called 'libgs.a' and 'libgs.so' which in our case would be a symlink to 'libgs.so.1.1.0' what will lead us to the next tag.
  

The <version/>-tag defines the current version with attributes major,minor,patch.

The <class/>-tag defines a c-CLASS:

• The name-attribute set the name
• A more detailed definition of the class itself (methods,...) will be done in a separate api-file

A class-tag with name 'shouter' would result in the generation of:

• include/shouter.h - which will be generated once and been updated in a specific block on following generate-calls (more about this later)
• src/shouter.c - generated once and never been touched afterwards

The <main/>-tag defines entrypoint(s) to use the library defined by the classes:

• The name-attribute defines the name of the main-executable.
• The private-attribute='1' marks this executable is 'internal tool' (not 100% sure what the consequence is. I guess it will have influence where and how this executable will be installed!?)

A main-tag with name 'tester' would result in the generation of:

• src/tester.c - generated once never been touched again
• building the project would result in an executable with the name 'tester'

Generating the project will be done with this command:

gsl project.xml

This will generate lots of files:

• autotools-buildfiles
• cmake-files
• include- and src-files
• ...

Since ZProject is quite interweaved with the zmq-ecosystem the skeleton adds a call to a czmq-class that can savely removed.

    //  Insert main code here
    if (verbose)
        zsys_info ("starter - ");

Also keep in mind that (at least at the moment) a non-default-constructor (defined in an api-file) will not generate a valid constructor. (more on this later)

Now, that we created our project and fixed that 'zsys_info'-situation we are ready to build.

You can build the project the autotools-way:

./autogen.sh
./configure
make

Or use cmake:

mkdir build
cd build
cmake ..
make

Both results will build your project.

Let's summarize:

• we created a first project.xml
• we generated code by using: 'gsl project.xml'
• we built our project

In the next part we will inspect what code is generated and how to add extend our classes.

Refs:
ZProject with lots of information about possible options
GSL