quasar.py command help

build (TODO this description is complete crap)

Method that generates the cmake headers, and after that calls make/vis-studio to compile your server.
Keyword arguments:
buildType – Optional parameter to specify Debug or Release build. If it is not specified it will default to Release.

build_config

    Prints the currently chosen build configuration file.
TODO: see also “set_build_config”

check_consistency

    Checks the consistency of the project, checking that all the files that must exist do exist, everything is in svn and the md5 keys are correct.
The following classes of errors might be reported:
  • checksum error of an internal quasar file (TODO description),

  • file not committed in the version control system,

  • file missing


clean

If you do in-source builds (the default), you can clean your repository from the build artifacts and temporary files.\

create_project

    Installs the framework in a given directory. If the directory doesn’t exist, it gets created

    Keyword arguments:
    destination – The target directory where the framework will be installed or upgraded

create_release


    Upgrades files.txt with the contents of original_files.txt. Expert command, only to be used by developers of the framework when creating a new release.
This command is strictly reserved to the quasar heads and it won’t work in a typical user environment.

design_vs_device

    Checks if the device files are outdated (By comparing with design), and hence if they should be regenerated.

doxygen

    Runs doxygen in the documentation folder, making the tool generate documentation for the server automatically.

enable_module

    Enables optional module. Module URL and required quasar version is downloaded from github.
       Module download is done later at cmake configure stage.

    Keyword arguments:
    moduleName   – name of the optional module
    tag          – tag/branch to checkout, if not specified, master branch is used
    serverString – default git server is “https://github.com”, specify custom if necessary, e.g. “ssh://git@gitlab.cern.ch:7999

disable_module

    Disables optional module. Module files will be deleted.

    Keyword arguments:
    moduleName – name of the optional module

external_tool_check

    Checks all of QUASAR dependencies to see if everything is setup as expected, and prints apropiate messages to point out what is missing.

format_design

    Formats design.xml. This is done to have always the same indentation format. The formatting is done in a separate file, in case something goes wrong, and then copied over.

generate as_doc

Generates address space documentation and places it in Documentation/AddressSpaceDoc.html.

generate asclass

    Generates the files AS<classname>.h and AS<classname>.cpp. This method is called automatically by cmake, it does not need to be called by the user.

    Keyword arguments:
    classname – the name of the device, which this class will be associated to.

generate base

    Generates the files Base_D<classname>.h and Base_D<classname>.cpp. This method is called automatically by cmake, it does not need to be called by the user.

    Keyword arguments:
    classname – the name of the device, which this class will be associated to.

generate cmake_headers

Generates CMake header lists in various directories, and then calls cmake.
Keyword arguments:
buildType – Optional parameter to specify Debug or Release build. If it is not specified it will default to Release.

generate config_cpp

Generates the file Configurator.cpp. This method is called automatically by cmake, it does not need to be called by the user.

generate config_doc

Generates documentation of the Configuration Schema.
Such a documentation is a HTML document with description of all fields that might appear in the configuration.

generate config_xsd

Generates the file Configuration.xsd. This method is called automatically by cmake, it does not need to be called by the user.

generate config_validator

    Generates the file ConfigValidator.xsd. This method is called automatically by cmake, it does not need to be called by the user.

generate device

    Generates the files D<classname>.h and D<classname>.cpp. This method needs to be called by the user, as this is the class where the device logic is, so a manual merge will be needed.

    Keyword arguments:
    classname – the name of the device, which this class will be associated to. You can specify several classes (up to 10), separated by spaces or just –all to regenerate all device classes.

generate device –all

Equal to “generate device” (above) run with all classes with device logic from the Design.

generate diagram

    Creates an UML diagram based on the classes of the server.

    Keyword arguments:
    detailLevel – Detail level of the diagram. If it is not present, 0 will be assumed

generate honkytonk

Generates honkyTonky.cc, a special class intended for testing your namespace with simulated (random) values.

generate info_model

 Generates the files ASInformationModel.h and ASInformationModel.cpp. This method is called automatically by cmake, it does not need to be called by the user.

generate source_variables


    Generates the files SourceVariables.h and SourceVariables.cpp. This method is called automatically by cmake, it does not need to be called by the user

generate root

Generates the files DRoot.h and DRoot.cpp. This method is called automatically by cmake, it does not need to be called by the user.

list_enabled_modules

List registered module URLs

list_modules

    Prints list of modules available on git server.

prepare_build

    Generates CMake header lists in various directories, and then calls cmake.

    Keyword arguments:
    buildType – Optional parameter to specify Debug or Release build. If it is not specified it will default to Release.

set_build_config

Sets the new build config. A build config file is a cmake file which specified the following aspects:
  • the kind of the OPC-UA backend chosen (e.g. UASDK or open62541),

  • the paths to the OPC-UA backend headers and libs,

  • boost libraries

TODO: see also “build_config” (above).

setup_svn_ignore

If you use SVN as your version control system, it setups the .svnignore file, so the generated files will be ignored in your svn repository.

upgrade_design

Method for adjusting Design.xml for a new Design.xsd when updating to a new version of the Framework

upgrade_project

    Upgrades the framework in a given directory

    Keyword arguments:
    destination – The target directory where the framework will be installed or upgraded

validate_design

Checks design.xml against Design.xsd, and after that performs some additional checks (defined in designValidation.xslt)