User:TvojaStara/sandbox

Bazel is a free and open-source software for managing the build process and automated testing of software in an reproducible and performant manner. It is designed to support large multilanguage codebases. Correctness in incremental builds is achieved by detecting changed files using a hash, not timestamp. On Linux, Bazel also isolates individual steps of the build process to ensure that only declared dependencies are being used. This ensures build and test results are independent on the environment.

Features
Bazel supports Java, Objective-C and C++. http://bazel.io/faq.html CMake can handle in-place and out-of-place builds, enabling several builds from the same source tree, and cross-compilation. The ability to build a directory tree outside the source tree is a key feature, ensuring that if a build directory is removed, the source files remain unaffected.

Another feature of CMake is the ability to generate a cache to be used with a graphical editor, which, when CMake is run, can locate executables, files and libraries. This information goes into the cache, which can then be tailored before generating the native build files.

Complicated directory hierarchies and applications that rely on several libraries are well supported by CMake. For instance, CMake is able to accommodate a project that has multiple toolkits, or libraries that each have multiple directories. In addition, CMake can work with projects that require executables to be created before generating code to be compiled for the final application. Its open-source, extensible design allows CMake to be adapted as necessary for specific projects.

CMake can generate makefiles for many platforms and IDEs including Unix, Windows, Mac OS X, OS/2, MSVC, Cygwin, MinGW and Xcode.

Microsoft Visual Studio
CMake scripts can produce Microsoft Visual Studio project and solution files. However, CMake syntax is more oriented towards Unix/Linux makefiles which is rather unfriendly for Visual Studio development which relies primarily on project->properties GUI.

Build process
The build process with CMake takes place in two stages. First, standard build files are created from configuration files. Then the platform's native build tools are used for the actual building.

Each build project contains a CMakeLists.txt file in every directory that controls the build process. The CMakeLists.txt file has one or more commands in the form COMMAND (args...), with COMMAND representing the name of each command and args the list of arguments, each separated by white space. While there are many built-in rules for compiling the software libraries (static and dynamic) and executables, there are also provisions for custom build rules. Some build dependencies can be determined automatically. Advanced users can also create and incorporate additional makefile generators to support their specific compiler and OS needs.

History
CMake development began in the year 1999 in response to the need for a cross-platform build environment for the Insight Segmentation and Registration Toolkit (ITK). The project is funded by the United States National Library of Medicine as part of the Visible Human Project. It was partially inspired by pcmaker, which was made by Ken Martin and other developers to support the Visualization Toolkit (VTK). At Kitware, Bill Hoffman blended components of pcmaker with his own ideas, striving to mimic the functionality of Unix configure scripts. CMake was first implemented in 2000 and further developed in 2001. Continued development and improvements were fueled by the incorporation of CMake into developers’ own systems, including:
 * The VXL Project
 * The CABLE; features added by Brad King
 * GE Corporate R&D for support of DART

Additional features were created when VTK transitioned to CMake for its build environment and for supporting ParaView.

Notable applications that use CMake

 * Allegro library
 * Armadillo - linear algebra library
 * Avidemux
 * awesome - window manager
 * BCI2000
 * Blender
 * BRL-CAD
 * Bullet Physics Engine
 * CGAL - Computational Geometry Algorithms Library
 * Chipmunk physics engine
 * CLion
 * Compiz
 * Conky
 * cURL
 * Deal.II
 * Doomsday Engine
 * Dust Racing 2D
 * Drishti
 * Ettercap
 * Falcon (programming language)
 * FlightGear Flight Simulator
 * GDCM
 * Geant4
 * Gmsh
 * GNU Radio
 * GROMACS
 * Hiawatha (web server)
 * Hypertable
 * Hugin
 * iCub robot and YARP
 * IGSTK
 * Insight Segmentation and Registration Toolkit (ITK)
 * KDE SC 4
 * KiCad
 * libpng
 * LAPACK
 * LLVM and Clang
 * LMMS
 * Mir
 * MiKTeX
 * MLPACK – machine learning library
 * MuseScore
 * MySQL and MariaDB
 * OGRE
 * OpenCV
 * OpenCog
 * OpenCPN
 * OpenSceneGraph
 * OpenSync
 * Orthanc
 * Point Cloud Library
 * Poppler
 * PvPGN
 * QGIS
 * Qt
 * Raw Therapee
 * ReactOS
 * ROOT
 * Robot Operating System (ROS)
 * Ryzom
 * Scribus
 * Second Life
 * SFML
 * Spring RTS
 * SuperTux
 * Synergy
 * Slicer
 * Stellarium
 * Trilinos
 * Vortexje
 * The Visualization Toolkit and ParaView
 * VXL
 * zlib
 * PCSX2
 * Zdoom
 * ZMQ

History
There are two previous major description languages, WSDL2.0 (Web Services Description Language) and WADL (Web Application Description Language). Neither is widely adopted in the industry for describing RESTful APIs, citing poor human readability of both and WADL being actually unable to fully describe a RESTful API.

List of RESTful API DLs

 * WSDL
 * WADL
 * OData
 * Swagger
 * developer: Reverb, https://helloreverb.com/
 * RAML
 * developer: Mulesoft, http://www.mulesoft.com/
 * Hypermedia
 * API Blueprint
 * I/O Docs
 * developer: Mashery, http://www.mashery.com/
 * Apache Avro
 * Barrister
 * http://barrister.bitmechanic.com/

List of data description languages
A significant part of RESTful API description is the specification of returned data structures. The IDL might either specify its own format or use an existing data description format. A notable example which many RESTful API DLs use is JSON Schema.


 * json:api
 * http://jsonapi.org/
 * Started as REST adapter for Ember Data
 * JSON Schema
 * used by Swagger, Google APIs Discovery, I/O Docs
 * Apache Avro
 * https://avro.apache.org/
 * both Interface Description Language and data description language
 * JSON-RPC 2.0
 * used by Barrister

Comparison of RESTful API DLs
The community around RESTful API DLs is vibrant and the landscape is still changing. According to a presentation by Akana, the most active projects in this area are Swagger, RAML and API Blueprint.