All Projects → CESNET → Libyang

CESNET / Libyang

Licence: bsd-3-clause
YANG data modeling language library

Programming Languages

c
50402 projects - #5 most used programming language

Labels

Projects that are alternatives of or similar to Libyang

Bancosbrasileiros
Lista de bancos brasileiros | Brazilian banks list
Stars: ✭ 178 (-21.59%)
Mutual labels:  json, xml
Iran
Administrative divisions of Iran in json and xml formats - تقسیمات کشوری ایران با فرمت جی‌سان و ایکس ام ال
Stars: ✭ 201 (-11.45%)
Mutual labels:  json, xml
Libxo
The libxo library allows an application to generate text, XML, JSON, and HTML output using a common set of function calls. The application decides at run time which output style should be produced.
Stars: ✭ 185 (-18.5%)
Mutual labels:  json, xml
Goxml2json
XML to JSON converter written in Go (no schema, no structs)
Stars: ✭ 170 (-25.11%)
Mutual labels:  json, xml
Apiproblem
A simple implementation of the api-problem specification. Includes PSR-15 support.
Stars: ✭ 225 (-0.88%)
Mutual labels:  json, xml
Node Js2xmlparser
Popular Node.js module for parsing JavaScript objects into XML
Stars: ✭ 171 (-24.67%)
Mutual labels:  json, xml
Xlog
Android logger, pretty, powerful and flexible, log to everywhere, save to file, all you want is here.
Stars: ✭ 2,468 (+987.22%)
Mutual labels:  json, xml
Uxdm
🔀 UXDM helps developers migrate data from one system or format to another.
Stars: ✭ 159 (-29.96%)
Mutual labels:  json, xml
Biblia
Bíblia: XML + SQL + JSON
Stars: ✭ 211 (-7.05%)
Mutual labels:  json, xml
Python Benedict
dict subclass with keylist/keypath support, I/O shortcuts (base64, csv, json, pickle, plist, query-string, toml, xml, yaml) and many utilities. 📘
Stars: ✭ 204 (-10.13%)
Mutual labels:  json, xml
Exportsheetdata
Add-on for Google Sheets that allows sheets to be exported as JSON or XML.
Stars: ✭ 170 (-25.11%)
Mutual labels:  json, xml
Parse
Go parsers for web formats
Stars: ✭ 224 (-1.32%)
Mutual labels:  json, xml
Acl
Server framework and network components written by C/C++ for Linux, Mac, FreeBSD, Solaris(x86), Windows, Android, IOS
Stars: ✭ 2,113 (+830.84%)
Mutual labels:  json, xml
Qxorm
QxOrm library - C++ Qt ORM (Object Relational Mapping) and ODM (Object Document Mapper) library - Official repository
Stars: ✭ 176 (-22.47%)
Mutual labels:  json, xml
Xresloader
跨平台Excel导表工具(Excel=>protobuf/msgpack/lua/javascript/json/xml)
Stars: ✭ 161 (-29.07%)
Mutual labels:  json, xml
Validation
validation api extracted from play
Stars: ✭ 194 (-14.54%)
Mutual labels:  json, xml
Gelatin
Transform text files to XML, JSON, or YAML
Stars: ✭ 150 (-33.92%)
Mutual labels:  json, xml
Serializer
With the Serializer component it's possible to handle serializing data structures, including object graphs, into array structures or other formats like XML and JSON. It can also handle deserializing XML and JSON back to object graphs.
Stars: ✭ 2,021 (+790.31%)
Mutual labels:  json, xml
Unbescape
Advanced yet easy to use escaping library for Java
Stars: ✭ 207 (-8.81%)
Mutual labels:  json, xml
Renderer
Simple, lightweight and faster response (JSON, JSONP, XML, YAML, HTML, File) rendering package for Go
Stars: ✭ 220 (-3.08%)
Mutual labels:  json, xml

libyang

BSD license Build Status codecov.io Coverity Scan Build Status Ohloh Project Status

libyang is a YANG data modelling language parser and toolkit written (and providing API) in C. The library is used e.g. in libnetconf2, Netopeer2, sysrepo and FRRouting projects.

Provided Features

  • Parsing (and validating) schemas in YANG format.
  • Parsing (and validating) schemas in YIN format.
  • Parsing, validating and printing instance data in XML format.
  • Parsing, validating and printing instance data in JSON format (RFC 7951).
  • Manipulation with the instance data.
  • Support for default values in the instance data (RFC 6243).
  • Support for YANG extensions.
  • Support for YANG Metadata (RFC 7952).
  • yanglint - feature-rich YANG tool.

Current implementation covers YANG 1.0 (RFC 6020) as well as YANG 1.1 (RFC 7950).

Branches

The project uses 2 main branches master and devel. Other branches should not be cloned. In master there are files of the last official release. Any latest improvements and changes, which were tested at least briefly are found in devel. On every new release, devel is merged into master.

This means that when only stable official releases are to be used, either master can be used or specific releases downloaded. If all the latest bugfixes should be applied, devel branch is the one to be used. Note that whenever a new issue is created and it occurs on the master branch, the first response will likely be to use devel before any further provided support.

Packages

We are using openSUSE Build Service to automaticaly prepare binary packages for number of GNU/Linux distros. The libyang packages are always build from current master branch (latest release). If you are interested in any other packages (such as devel or C++ and Python bindings), you can browse all packages from our repository.

Requirements

Build Requirements

  • C compiler (gcc >= 4.8.4, clang >= 3.0, ...)
  • cmake >= 2.8.12
  • libpcre (devel package)
  • note, that PCRE is supposed to be compiled with unicode support (configure's options --enable-utf and --enable-unicode-properties)
  • cmocka >= 1.0.0 (for tests only, see Tests)

Optional

  • doxygen (for generating documentation)
  • valgrind (for enhanced testing)

Runtime Requirements

  • libpcre

Building

$ mkdir build; cd build
$ cmake ..
$ make
# make install

Documentation

The library documentation can be generated directly from the source codes using Doxygen tool:

$ make doc
$ google-chrome ../doc/html/index.html

The documentation is also built hourly and available at netopeer.liberouter.org.

Useful CMake Options

Changing Compiler

Set CC variable:

$ CC=/usr/bin/clang cmake ..

Changing Install Path

To change the prefix where the library, headers and any other files are installed, set CMAKE_INSTALL_PREFIX variable:

$ cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr ..

Default prefix is /usr/local.

Build Modes

There are two build modes:

  • Release. This generates library for the production use without any debug information.
  • Debug. This generates library with the debug information and disables optimization of the code.

The Debug mode is currently used as the default one. to switch to the Release mode, enter at the command line:

$ cmake -D CMAKE_BUILD_TYPE:String="Release" ..

Changing Extensions Plugins Directory

As for YANG extensions, libyang allows loading extension plugins. By default, the directory to store the plugins is LIBDIR/libyang. To change it, use the following cmake option with the value specifying the desired directory:

$ cmake -DPLUGINS_DIR:PATH=`pwd`"/src/extensions/" ..

The directory path can be also changed runtime via environment variable, e.g.:

$ LIBYANG_EXTENSIONS_PLUGINS_DIR=`pwd`/my/relative/path yanglint

Optimizations

Whenever the latest revision of a schema is supposed to be loaded (import without specific revision), it is performed in the standard way, the first time. By default, every other time when the latest revision of the same schema is needed, the one initially loaded is reused. If you know this can cause problems meaning the latest available revision of a schema can change during operation, you can force libyang to always search for the schema anew by:

$ cmake -DENABLE_LATEST_REVISIONS=OFF ..

Also, it can be efficient to store certain information about schemas that is generated during parsing so that it does not need to be generated every time the schema is used, but it will consume some additional space. You can enable this cache with:

$ cmake -DENABLE_CACHE=ON ..

CMake Notes

Note that, with CMake, if you want to change the compiler or its options after you already ran CMake, you need to clear its cache first - the most simple way to do it is to remove all content from the 'build' directory.

Usage

All libyang functions are available via the main header:

#include <libyang/libyang.h>

To compile your program with libyang, it is necessary to link it with libyang using the following linker parameters:

-lyang

Note, that it may be necessary to call ldconfig(8) after library installation and if the library was installed into a non-standard path, the path to libyang must be specified to the linker. To help with setting all the compiler's options, there is libyang.pc file for pkg-config(1) available in the source tree. The file is installed with the library.

If you are using cmake in you project, it is also possible to use the provided FindLibYANG.cmake file to detect presence of the libyang library in the system.

yanglint

libyang project includes a feature-rich tool called yanglint(1) for validation and conversion of the schemas and YANG modeled data. The source codes are located at /tools/lint and can be used to explore how an application is supposed to use the libyang library. yanglint(1) binary as well as its man page are installed together with the library itself.

There is also README describing some examples of using yanglint.

libyang supports YANG extensions via a plugin mechanism. Some of the plugins (for NACM or Metadata) are available out of the box and installed together with libyang. However, when libyang is not installed and yanglint(1) is used from the build directory, the plugins are not available. There are two options:

  1. Install libyang.
# make install
  1. Set environment variable LIBYANG_EXTENSIONS_PLUGINS_DIR to contain path to the built extensions plugin (./src/extensions from the build directory).
$ LIBYANG_EXTENSIONS_PLUGINS_DIR="`pwd`/src/extensions" ./yanglint

Windows

There is an unofficial Windows port of this library available.

Tests

libyang includes several tests built with cmocka. The tests can be found in tests subdirectory and they are designed for checking library functionality after code changes.

The tests are by default built in the Debug build mode by running

$ make

In case of the Release mode, the tests are not built by default (it requires additional dependency), but they can be enabled via cmake option:

$ cmake -DENABLE_BUILD_TESTS=ON ..

Note that if the necessary cmocka headers are not present in the system include paths, tests are not available despite the build mode or cmake's options.

Tests can be run by the make's test target:

$ make test

Fuzzing

Simple fuzzing targets, fuzzing instructions and a Dockerfile that builds the fuzz targets and the AFL fuzzer are available in the tests/fuzz directory.

The tests/fuzz directory also contains a README file that describes the whole process in more detail.

Bindings

We provide bindings for high-level languages using SWIG generator. The bindings are optional and to enable building of the specific binding, the appropriate cmake option must be enabled, for example:

$ cmake -DJAVASCRIPT_BINDING=ON ..

More information about the specific binding can be found in their README files.

Currently supported bindings are:

  • JavaScript
    • cmake option: JAVASCRIPT_BINDING
    • README
  • Python SWIG (uses SWIG, enabled by default if GEN_LANGUAGE_BINDINGS is set)
    • cmake option: GEN_PYTHON_BINDINGS (depends on GEN_CPP_BINDINGS)
    • README
  • Python CFFI (more "pythonic" API)

Project Information

Project is hosted on GitHub where you can find additional information and contact developers via the project's issue tracker. If you are interested in future plans announcements, please subscribe to the Future Plans issue.

Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].