Skip to content
Martin Kojtal edited this page Dec 3, 2019 · 14 revisions

Each tool has specific settings. This section describes what options are available per tool. The value for each attribute depends on the tool definition.

An option which supports multiple options should be defined as:

Misccontrols:
- debug
-g

Most of the tools support templates or misc options.

Template is a project file which gets parsed and used for generating a project.

Misc options mis there are various tool specific options (in many cases there's standard way - c/cxx/asm/ld flags). So besides those flags, a tool can provide specific options like setting localhost address and similar. Look at the tool what options it provides.

An example of misc options for IAR:

iar:
    misc:
        c_flags:
        - --dlib_config
        - --dlib_config
        cxx_flags:
        - --cxx_flags_test
        - --cxx_flags_test
        ld_flags:
        - --misrac2004
        - --misrac2004
        asm_flags:
        - --asm_flags_test
        - --asm_flags_test
### uVision attributes

uVision supports templates and also misc options (they can be combined).

Misc options means there are c/cxx/asm/ld flags which uvision supports. Look at armcc/armlink/armasm flags which are supported. For instance, cxx_flag is --cpp11, which enables c++11.

### IAR attributes

IAR supports templates and misc options (they can be combined).

Misc options means there are c/cxx/asm/ld flags which IAR supports. Look at IAR devel guide which lists all available flags.

### CoIDE attributes

Not needed, they are taken from the project template.

This tool does not provide any misc options, as it can't be invoked via command line like other tools.

### Makefile (GCC ARM) attributes

As we are using custom makefile, there's no template support.

Misc options are supported. It can be c/cxx/asm/ld flags, common_flags, standard_libraries..

### Makefile (ARMCC) attributes

As we are using custom makefile, there's no template support.

Misc options are supported. Look at armcc/armlink/armasm flags which are supported. For instance, a cxx_flag is --cpp11, which enables c++11. It can be c/cxx/asm/ld flags, common_flags, standard_libraries..

### Eclipse Makefile GNU ARM attributes

As Eclipse project is based on Makefile, the attributes are the same as for Makefile.

### CMake attributes

As we are using custom cmake, there's no template support.

Misc options are supported. It can be c/cxx/asm/ld flags, common_flags, standard_libraries.

## Add new tool

There are two base classes for our tools, Tool and Exporter. They can be found in tools/tool.py file. They provide basic tool functionality, a new tool should inherit from this classes and provide own implementation of their methods.

Lets implement a MyNewTool tool which we would like to add to progen tools.

class MyNewTool(Tool, Exporter):
    def __init__(self, workspace, env_settings):
        self.workspace = workspace
        self.env_settings = env_settings

    @staticmethod
    def get_toolnames():
        return ['my_new_tool']

    @staticmethod
    def get_toolchain():
        return 'toolchain_name'

    def export_project(self):
        # any additional processing of progen data (workspace)
        # generate files using Exporter methods gen_file_raw (write data to file)
        # or using jinja2 gen_file_jinja
        self.gen_files = self.gen_file_jinja(self.workspace)

        # returns generated project files, important for any post processing or building 
        return self.gen_Files

    def export_workspace(self):
        # might not do anything as workspace might not be supported

    def get_generated_files(self):
        return {'path': self.gen_files['path'], 'files': self.gen_files['this_file']}

This should be a boilerplate for any tool in progen.

For generating a project, jinja2 template project file can be provided or python implementation which transforms data to a valid project file format (xml for instance). It's easier to start with jinja2 template file. Generate a valid project file in your tool. We need to find there where are source, includes, target, debugger and other data stored, to be able to inject progen data. For more info about what data progen uses,s look at Record wiki page.

If you are interested in using python template implementation, this example might help you. To get a template to python, for instance using a project file written in xml format:

import xmltodict                                                               
print xmltodict.parse(file('lpc1768_blinky.vcxproj.user'))  

Store the output from the file, and create a python dict vcxproj.user = output_here. This dictionary then can be used by our tool to inject progen data, do any preprocessing and transform data back to xml format, generate raw file. As an example, look at uvision or IAR which is implemented with this method.

There are several tests that we strongly encourage you to add when adding a toolchain to progen. The tests that we recomend adding are a build test, located in tests/test_commands/test_build.py; a tool supported test, located in tests/tests_tools_supported.py; and a generation test in tests/test_tools/test_{toolchain}.py.