# Checkout note

> `Magento\Checkout\Model\PaymentInformationManagement::savePaymentInformationAndPlaceOrder`

Endpoint for placing order, it performs:

1. validate the payment method
2. trigger payment method command 
    - authorize


# Payment Processing

`Magento\Payment\Gateway\Command\GatewayCommand::execute`

this method has 1 array parameter which contain:

- payment (Magento\Payment\Gateway\Data\PaymentDataObject)
    - order (Magento\Payment\Gateway\Data\Order\OrderAdapter)
    - payment (Magento\Sales\Model\Order\Payment)
- amount (int)

# Building mxnet from source

1. git clone **recursively** from github

		git clone --recursive https://github.com/apache/incubator-mxnet mxnet

2. use cmake
	1. **Don't use JEMALLOC**, it screwes you, USE_JEMALLOC=0
    2. First **don't use CPP_PACKAGE**, because OpWrapperGenerator.py needs libmxnet.so first and then OpWrapperGenerator.py will use it afterwards
    
            cmake -DUSE_JEMALLOC=0 -DUSE_CPP_PACKAGE=0 ..
            make -j4
	
    3. Then we can **use CPP_PACKAGE** to compile for c++ package support
    
            cmake -DUSE_JEMALLOC=0 -DUSE_CPP_PACKAGE=1 ..
            make -j4
        

# What are Shared Libraries in C?

Shared libraries are libraries that use dynamic linking vs static linking in the compilation steps for compiling a file. Static and dynamic linking are two processes of collecting and combining multiple object files in order to create a single executable file. The main difference between the two is the type of linking they do when creating an executable file.

Dynamic linking defers much of the linking process until a program starts running. Compared to static libraries where a file in compiled and all the machine code is put into an executable file at compile time, dynamic linking performs the linking process “on the fly” as programs are executed in the system. In dynamic linking, dynamic libraries are loaded into memory by programs when they start. When you compile a shared library, the machine code is then stored on your machine, so when you recompile the program that has newly added code to it, the compilation process just adds the new code and store it to memory vs. recompiling an entire file into an executable file like a static library.

# How to create Shared Libraries?

	gcc -g -fPIC -Wall -Werror -Wextra -pedantic *.c -shared -o libholberton.so

The `-g` flag include debugging information

The `-fPIC` flag enables “position independent code” generation, which is a requirement for shared libraries. This allows the code to be located/executed at any virtual address at runtime.

The `-shared` flag created a shared library, hence the .so extension for shared object. The `-o` created an output file. When you use both, you created a shared output file name libholberton.so.

The `-Wall -Wextra -pendantic` flags are all warning and error flags that should be included when compiling your code

When we use this sequence of flags with the `gcc` command, we are compiling all the C files in the current directory and created a shared library called libholberton.so that now exists in memory on our machine.

If we have C files that provide some sort of functionality that we want to use in a shared library, we use the command above to create a shared library that now will be able to be reference the shared library in memory instead of recompiling an entire file.

# How to use the Shared Libraries?

	$ gcc -Wall -Werror -Wextra -pedantic -L. 0-main.c -lholberton -o len

We’ve created a shared library called libholberton.so and now we want to use it on a file called 0-main.c . So what do we do it? Use the command above.

The **-L** after the library name telling the linker that the library might be found in the current directory

The **0-main.c** file is the file we want to use that references the shared library to execute our program

The **-lholberton** flag is the shared library name without the .so extension.

The *-o* flag is to create an executable filename len

After running the command, we now have an executable file name len that references the shared library libholberton.so which is stored in memory in our machine. If you then run the len executable file, it will not work because there’s one step you need to do before executing the len file! You need to set your LD_LIBRARY_PATH environment variable so that the runtime linker can find and load your .so file into the executable at runtime.

	$ export LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH

The command above installs the library into your current working directory. To install it in your /usr/lib folder, use the command below:

	$ export LD_LIBRARY_PATH=$HOME/lib:$LD_LIBRARY_PATH

Now you can use your len executable file, which prints out the length of the string “Holberton” which is 9. Enjoy.


# Differences between Shared and Static Libraries?
## Static Libraries

### Advantages:

* Speed
* All the code to execute the file is in one executable file, with little to virtually zero compatibility issues

### Disadvantages:

* Constant load time every time a file is compiled and recompiled
* Larger in size because the file has to be recompiled every time when adding new code to the executable

## Shared Libraries:

### Advantages:

* executable program
* Dynamic linking load time will be reduced if the shared library code is already present in memory

### Disadvantages:

* Slower execution time compared to static libraries
* Potential compatibility issues if a library is changed without recompiling the library into memory

Questions, comments or concerns, feel free to comment below, follow me or find me on Twitter @ NTTL_LTTN.

## Flutter Container MaxWidth

```
Container(
constraints: BoxConstraints(maxWidth:200)
...
)
```

## 分割

將`store`分割成`module`，每個`module`擁有自己的`state`、`mutation`、`action`、`getter`

```javascript
const moduleA = {
  namespaced: true,
  state: { ... },
  mutations: { ... },
  actions: { ... },
  getters: { ... }
}

const moduleB = {
  state: { ... },
  mutations: { ... },
  actions: { ... }
}

const store = new Vuex.Store({
  modules: {
    moduleA,
    moduleB
  }
})

store.state.moduleA // -> moduleA 的state狀態
store.state.moduleB // -> moduleB 的state狀態
```

## Module local status

module 內部的`mutation`和`getter`，接收的第一個參數為**Module 作用域物件**

```javascript
const moduleA = {
  namespaced: true,
  // count會寫到全域
  // 取用方法: $store.state.moduleA.count
  state: { count: 0 },
  mutations: {
    increment(state) {
      // state: Module 作用域物件
      state.count++
    }
  },

  getters: {
    // 取用方法: $store.getters.moduleA.doubleCount
    // 或: $store.rootGetters.doubleCount
    doubleCount(state) {
      return state.count * 2
    }
  }
}
```

`action`同樣也是使用**Module 作用域物件**

```javascript
const moduleA = {
  // ...
  actions: {
    // state: 作用域狀態
    // rootState: 根節點狀態
    actionIncrement({ state, commit, rootState }) {
      if ((state.count + rootState.count) % 2 === 1) {
        commit('increment')
      }
    }
  }
}
```

## 命名空間

默認情況下，模塊內部的 `action`、`mutation` 和 `getter` 是註冊在**全域命名空間**的

這樣使得多個模塊能夠對同一 `mutation` 或 `action` 作出響應

通過添加 `namespaced: true` 的方式使其成為帶命名空間的模塊

當模塊被註冊後，它的所有 `getter`、`action` 及 `mutation` 都會自動根據**模塊註冊的路徑**調整命名

```javascript
const store = new Vuex.Store({
  modules: {
    account: {
      namespaced: true,

      // 模塊內容（module assets）
      // 模塊內的狀態已經是嵌套的了，使用 `namespaced` 屬性不會對其產生影響
      state: { ... },
      getters: {
        isAdmin () { ... } // -> getters['account/isAdmin']
      },
      actions: {
        login () { ... } // -> dispatch('account/login')
      },
      mutations: {
        login () { ... } // -> commit('account/login')
      },

      // 嵌套模塊
      modules: {
        // 繼承父模塊的命名空間
        myPage: {
          state: { ... },
          getters: {
            profile () { ... } // -> getters['account/profile']
          }
        },

        // 進一步嵌套命名空間
        posts: {
          namespaced: true,

          state: { ... },
          getters: {
            popular () { ... } // -> getters['account/posts/popular']
          }
        }
      }
    }
  }
})
```

#### 帶命名空間的綁定函數

使用`mapState`、`mapGetters`、`mapActions` 和 `mapMutations`

通過使用 `createNamespacedHelpers` 創建基於某個命名空間輔助函數

可用於找**本身和別人**的`state`

```javascript
// 注意這一段
import { createNamespacedHelpers } from 'vuex'

const { mapState, mapActions } = createNamespacedHelpers('some/nested/module')

export default {
  computed: {
    // 在 `some/nested/module` 中查找
    ...mapState({
      a: state => state.a,
      b: state => state.b
    })
  },
  methods: {
    // 在 `some/nested/module` 中查找
    ...mapActions(['foo', 'bar'])
  }
}
```

issueを起票しての修正の場合  
Fix for #123456

一つのコミットでissueが解決しない場合  
`何やったか` #123456

**include_directories** is used to supply a list of include directories to the compiler. When a file is included using the pre-processor, these directories will be searched for the file.

**link_libraries** is used to supply a list of libraries (object archives) to the linker. If the linked item is a cmake target, with specified include directories, they don't need to be specified separately with.

**link_directories** specify directories in which the linker will look for libraries

The **target_*** versions apply only to the target that is given as an operand. The non-target versions apply to all targets in the directory. The target_* versions should be used whenever possible (i.e. pretty much always).

**find_package** is used to search for cmake settings from external sources i.e. outside of the project. If you want to link with a library without including the source of the library in a sub directory of your project, then you use find_package. From a lower level point of view, find_package(Foo) looks for a cmake module FindFoo.cmake and executes the module. The purpose of the module is to generate cmake variables or targets that can be used to include the corresponding dependency.

**add_executable** it creates executable files (on windows it is .exe)

**add_library** is similar to add_executable, except it adds a target for a library, rather rather than an executable. Library targets can be used as items in link_libraries, and their dependencies are transitive by default.

All of these have to do with libraries in general. Except **include_directories** are also used for specifying the include directory of the project's own header files, not only those of the libraries.

If the **find_package** module has created a cmake target for the library (using add_library(... IMPORTED)), which itself specifies the dependencies of the dependency, then simply link with it using link_libraries, and cmake takes care of linking with the dependencies. Same goes for the include directory of the target.

Old cmake modules don't necessarily provide targets, in which case you may need to write your own module in order to avoid bloating the project configuration.

**include** this include other `.cmake` files. Usually with cmakefile function definitions and etc

[Original article](https://medium.com/@onur.dundar1/cmake-tutorial-585dd180109b)

# Introduction

CMake is an extensible, open-source system that manages the build process in an operating system and in a compiler-independent manner.

Unlike many cross-platform systems, CMake is designed to be used in conjunction with the native build environment. Simple configuration files placed in each source directory (called CMakeLists.txt files) are used to generate standard build files (e.g., Makefiles on Unix and projects/workspaces in Windows MSVC) which are used in the usual way.

CMake can generate a native build environment that will compile source code, create libraries, generate wrappers and build executable binaries in arbitrary combinations. CMake supports in-place and out-of-place builds, and can therefore support multiple builds from a single source tree.

CMake has supports for static and dynamic library builds. Another nice feature of CMake is that it can generates a cache file that is designed to be used with a graphical editor. For example, while CMake is running, it locates include files, libraries, and executables, and may encounter optional build directives. This information is gathered into the cache, which may be changed by the user prior to the generation of the native build files.

CMake scripts also make source management easier because it simplifies build script into one file and more organized, readable format.
Popular Open Source Project with CMake

Here is a list of popular open source projects using CMake for build purposes:

    OpenCV: https://github.com/opencv/opencv
    Caffe2: https://github.com/caffe2/caffe2
    MySql Server: https://github.com/mysql/mysql-server

See Wikipedia for a longer list [https://en.wikipedia.org/wiki/CMake#Applications_that_use_CMake](https://en.wikipedia.org/wiki/CMake#Applications_that_use_CMake)

It is always a good practice to read open source projects, which are widely used to learn about the best practices.

# CMake as a Scripting Language

CMake intended to be a cross-platform build process manager so it defines it is own scripting language with certain syntax and built-in features. CMake itself is a software program, so it should be invoked with the script file to interpret and generate actual build file.

A developer can write either simple or complex building scripts using CMake language for the projects.

Build logic and definitions with CMake language is written either in CMakeLists.txt or a file ends with <project_name>.cmake. But as a best practice, main script is named as CMakeLists.txt instead of .cmake.

    CMakeLists.txt file is placed at the source of the project you want to build.
    CMakeLists.txt is placed at the root of the source tree of any application, library it will work for.
    If there are multiple modules, and each module can be compiled and built separately, CMakeLists.txt can be inserted into the sub folder.
    .cmake files can be used as scripts, which runs cmake command to prepare environment pre-processing or split tasks which can be written outside of CMakeLists.txt.
    .cmake files can also define modules for projects. These projects can be separated build processes for libraries or extra methods for complex, multi-module projects.

Writing Makefiles might be harder than writing CMake scripts. CMake scripts by syntax and logic have similarity to high level languages so it makes easier for developers to create their cmake scripts with less effort and without getting lost in Makefiles.

# CMake Commands

CMake commands are similar to C++/Java methods or functions, which take parameters as a list and perform certain tasks accordingly.

CMake commands are case insensitive. There are built-in commands, which can be found from cmake documentation: https://cmake.org/cmake/help/latest/manual/cmake-commands.7.html

Some commonly used commands

    message: prints given message
    cmake_minimum_required: sets minimum version of cmake to be used
    add_executable: adds executable target with given name
    add_library: adds a library target to be build from listed source files
    add_subdirectory: adds a subdirectory to build

There are also commands to enable developers write out conditional statements, loops, iterate on list, assignments:

    if, endif
    elif, endif
    while, endwhile
    foreach, endforeach
    list
    return
    set_property (assign value to variable.)

Indentation is not mandatory but suggested while writing CMake scripts. CMake doesn’t use ‘;’ to understand end of statement.

All conditional statements should be ended with its corresponding end command (endif, endwhile, endforeachetc)

All these properties of CMake help developers to program complex build processes including multiple modules, libraries and platforms.

For example, KDE has its own CMake style guideline as in following URL:

    https://community.kde.org/Policies/CMake_Coding_Style

# CMake Environment Variables

Environment variables are used to configure compiler flags, linker flags, test configurations for a regular build process. Compiler have to be guided to search for given directories for libraries.

A detailed list of environment variables can be seen from following URL:

    https://cmake.org/cmake/help/latest/manual/cmake-env-variables.7.html

Some of the environment variables are overriden by predefined CMake Variables. e.g. CXXFLAGS is overriden when CMAKE_CXX_FLAGS is defined.

Below is an example use case, when you want to enable all warnings during compile process, you may write -Wall to build command. If you are building your code with CMake, you can add -Wall flag with using set command.

    set(CMAKE_CXX_FLAGS "-Wall")
    # append flag, best practice, suggested, don't lose previously defined flags
    set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall")

# CMake Variables

CMake includes predefined variables which are set by default as location of source tree and system components.

Variables are case-sensitive, not like commands. You can only use alpha numeric chars and underscore, dash (_, -) in definition of variable.

You can find more details about CMake variables in the following URLs

    https://cmake.org/cmake/help/v3.0/manual/cmake-language.7.html#variables
    https://cmake.org/cmake/help/v3.0/manual/cmake-variables.7.html#manual:cmake-variables(7)

Some of the variables can be seen as below, these are predefined according to root folder:

    CMAKE_BINARY_DIR: Full path to top level of build tree and binary output folder, by default it is defined as top level of build tree.
    CMAKE_HOME_DIRECTORY: Path to top of source tree
    CMAKE_SOURCE_DIR: Full path to top level of source tree.
    CMAKE_INCLUDE_PATH: Path used to find file, path

Variable values can be accessed with ${<variable_name>}.

    message("CXX Standard: ${CMAKE_CXX_STANDARD}")
    set(CMAKE_CXX_STANDARD 14)

Just like above variables, you can define your own variables. You can call set command to set a value to a new variable or change value of existing variable like below:

    set(TRIAL_VARIABLE "VALUE")
    message("${TRIAL_VARIABLE}")

# CMake Lists
Photo by Kelly Sikkema on Unsplash

All values in CMake are stored as string but a string can be treated as list in certain context.

A list of elements represented as a string by concatenating elements separated by semi-column ‘;’.

    set(files a.txt b.txt c.txt)
    # sets files to "a.txt;b.txt;c.txt"

In order to access the list of values you can use foreach command of CMake as following:

    foreach(file ${files})
        message("Filename: ${file}")
    endforeach()

# CMake Generator Expressions

Generator expressions are evaluated during build system generation to produce information specific to each build configuration.

Generator expressions are allowed in the context of many target properties, such as LINK_LIBRARIES, INCLUDE_DIRECTORIES, COMPILE_DEFINITIONS and others. They may also be used when using commands to populate those properties, such as target_link_libraries(), target_include_directories(), target_compile_definitions() and others.

https://cmake.org/cmake/help/v3.3/manual/cmake-generator-expressions.7.html

# Start Building C++ Code with CMake
Photo by Oscar Nord on Unsplash

In previous sections, we have covered the core principles of writing CMake scripts. Now, we can continue to write actual scripts to start building C++ code.

We can just start with a basic “Hello World!” example with CMake so we wrote the following “Hello CMake!” the main.cpp file as following:

    #include <iostream>
    int main() {
        std::cout<<"Hello CMake!"<<std::endl;
    }

Our purpose is to generate a binary to print “Hello CMake!”.

If there is no CMake we can run compiler to generate us a target basically with only following commands.

```bash
$ g++ main.cpp -o cmake_hello
```

CMake helps to generate bash commands with the instructions you gave, for this simple project we can just use a simple CMakeLists.txt which creates Makefile for you to build binary.

It is obvious that, for such a small project it is redundant to use CMake but when things get complicated it will help a lot.

In order to build main.cpp, using add_executable would be enough, however, let’s keep things in order and write it with proper project name and cmake version requirement as below:

cmake_minimum_required(VERSION 3.9.1)project(CMakeHello)add_executable(cmake_hello main.cpp)

When the script ready, you can run cmake command to generate Makefile/s for the project.

You will notice that, cmake is identifying compiler versions and configurations with default information.

```bash
$ cmake CMakeLists.txt
-- The C compiler identification is AppleClang 9.0.0.9000039
-- The CXX compiler identification is AppleClang 9.0.0.9000039
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/User/Projects/CMakeTutorial
```

When cmake finishes its job, Makefile will be generated together with CMakeCache.txt and some other artefects about build configuration. You can run make command to build project.

```bash
$ make all
#or
$ make cmake_hello
```

Let’s make things little more complicated.

What if your code is depended on C++14 or later. If you look for C++14 specifications, you see that, return type deduction has been introduced with C++14, lets add a new method to our main.cpp with auto return type as below.

```cpp
#include <iostream>auto sum(int a, int b){
        return a + b;
}int main() {
        std::cout<<"Hello CMake!"<<std::endl;
        std::cout<<"Sum of 3 + 4 :"<<sum(3, 4)<<std::endl;
        return 0;
}
```

If you try to build above code with default settings, you could get an error about auto return type because most hosts configured to work C++99 config by default. Therefore you should point your compiler to build with C++14 with setting CMAKE_CXX_STANDARD variable to 14. If you want to add C++14 on command line, you can set -std=c++14.

CMake generates Makefile with defaults settings which is mostly lower than C++14, so you should add 14 flag as seen below.

cmake_minimum_required(VERSION 3.9.1)project(CMakeHello)set(CMAKE_CXX_STANDARD 14)add_executable(cmake_hello main.cpp)

Now, you should be able to build it correctly. (cmake command would work even though you didn’t add 14 standard but make command would return error.)

CMake eases building process for you; especially when you do cross compile to make sure you are working with correct version of compiler with correct configurations, this will enable multiple developers to use same building configurations across all machines including build server and developer PC.

What if, you want to build for multiple platforms:

    generate executables for Windows, Mac and Linux separetely.
    add different macros for Linux Kernel version later than X.

Following variables can be used to check for system related information: Pasted from: https://cmake.org/Wiki/CMake_Checking_Platform

    CMAKE_SYSTEM
    the complete system name, e.g. "Linux-2.4.22", "FreeBSD-5.4-RELEASE" or "Windows 5.1"
    CMAKE_SYSTEM_NAME
    The name of the system targeted by the build. The three common values are Windows, Darwin, and Linux, though several others exist, such as Android, FreeBSD, and CrayLinuxEnvironment. Platforms without an operating system, such as embedded devices, are given Generic as a system name.
    CMAKE_SYSTEM_VERSION
    Version of the operating system. Generally the kernel version.
    CMAKE_SYSTEM_PROCESSOR
    the processor name (e.g. "Intel(R) Pentium(R) M processor 2.00GHz")
    CMAKE_HOST_SYSTEM_NAME
    The name of the system hosting the build. Has the same possible values as CMAKE_SYSTEM_NAME.

Let’s check if build system is Unix or Windows.

cmake_minimum_required(VERSION 3.9.1)project(CMakeHello)set(CMAKE_CXX_STANDARD 14)# UNIX, WIN32, WINRT, CYGWIN, APPLE are environment variables as flags set by default system

```cmake
if(UNIX)
    message("This is a ${CMAKE_SYSTEM_NAME} system")
elseif(WIN32)
    message("This is a Windows System")
endif()# or use MATCHES to see if actual system name 
# Darwin is Apple's system name
if(${CMAKE_SYSTEM_NAME} MATCHES Darwin)
    message("This is a ${CMAKE_SYSTEM_NAME} system")
elseif(${CMAKE_SYSTEM_NAME} MATCHES Windows)
    message("This is a Windows System")
endif()add_executable(cmake_hello main.cpp)
```

System information checks your build system other than building correct binary, like using macros. You can define compiler macros to send to code during build process to change behavior.

Large code bases are implemented to be system agnostic with macros to use certain methods only for the correct system. That also prevents errors, next section shows how to define a macro and use in code.
Defining Macros using CMake
“Close-up of lines of code on a computer screen” by Ilya Pavlov on Unsplash

Macros help engineers to build code conditionally to discard or include certain methods according to running system configurations.

You can define macros in CMake with add_definitions command, using -D flag before the macro name.

Lets define macro named CMAKEMACROSAMPLE and print it in the code.

cmake_minimum_required(VERSION 3.9.1)project(CMakeHello)set(CMAKE_CXX_STANDARD 14)# or use MATCHES to see if actual system name 

```cmake
# Darwin is Apple's system name
if(${CMAKE_SYSTEM_NAME} MATCHES Darwin)
    add_definitions(-DCMAKEMACROSAMPLE="Apple MacOS")
elseif(${CMAKE_SYSTEM_NAME} MATCHES Windows)
    add_definitions(-DCMAKEMACROSAMPLE="Windows PC")
endif()add_executable(cmake_hello main.cpp)
```
Below is the new main.cpp with printing macro.
```cpp
#include <iostream>
#ifndef CMAKEMACROSAMPLE
#define CMAKEMACROSAMPLE "NO SYSTEM NAME"
#endifauto 
sum(int a, int b){
        return a + b;
}
int main() {
        std::cout<<"Hello CMake!"<<std::endl;
		std::cout<<CMAKEMACROSAMPLE<<std::endl;
        std::cout<<"Sum of 3 + 4 :"<<sum(3, 4)<<std::endl;
        return 0;
}
```

# CMake Folder Organization

While building applications, we try to keep source tree clean and separate auto-generated files and binaries.

For CMake, many developers prefer to create a build folder under root tree and start CMake command inside, as below. Make sure you did cleaned all previously generate files (CMakeCache.txt), otherwise it doesn’t creates files inside build.
```bash
$ mkdir build
$ cmake ..
$ ls -all
-rw-r--r--   1 onur  staff  13010 Jan 25 18:40 CMakeCache.txt
drwxr-xr-x  15 onur  staff    480 Jan 25 18:40 CMakeFiles
-rw-r--r--   1 onur  staff   4964 Jan 25 18:40 Makefile
-rw-r--r--   1 onur  staff   1256 Jan 25 18:40 cmake_install.cmake
$ make all
```

Above commands creates build files inside build directory. It is called out-source build.

You can add build/ folder to your .gitignore to disable tracking.

At this time, you can not force CMake with variables to force creating artefacts into another folder with setting variables so if you don’t want to create a directory and cd into it, you can also use below command to create folder and generate files inside it. -H and -B flags will help it.

    -H points the source tree root.
    -B points the build directory.

```
$ cmake -H. -Bbuild
# H indicates source directory
# B indicates build directory
# For CLion, you can navigate to CLion -> Preferences -> Build, Execution and Deployment -> CMake -> Generation Path
```

However, you can write script in CMake to manipulate where the libraries will be, executables will be.

Let’s edit our CMakeLists.txt to generate binary file inside bin folder with setting CMAKE_RUNTIME_OUTPUT_DIRECTORY or EXECUTABLE_OUTPUT_PATH.

```
cmake_minimum_required(VERSION 3.9.1)project(CMakeHello)set(CMAKE_CXX_STANDARD 14)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall")set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)add_executable(cmake_hello main.cpp)
```

After building the project, cmake_hello binary will be generated inside build/bin folder.

Same procedure can be done for library paths as well for shared libraries (.dll or .so) with following variables.

    LIBRARY_OUTPUT_PATH
    CMAKE_LIBRARY_OUTPUT_DIRECTORY

Or you can use archive output paths for static libraries (.a or .lib)

    CMAKE_ARCHIVE_OUTPUT_DIRECTORY
    ARCHIVE_OUTPUT_PATH

In some cases, setting single path can be enough, but for larger projects with multiple modules, you may need to write cmake scripts to manage folders to easily organize build structure. This will help you to pack and deploy, install the generated executables, libraries, documents with certain folders.

It is a common practice to disable in-source building. Following script can be used to block in-source building.

    Source of script OpenCV Project: https://github.com/opencv/opencv/blob/master/CMakeLists.txt

# Disable in-source builds to prevent source tree corruption.
if(" ${CMAKE_SOURCE_DIR}" STREQUAL " ${CMAKE_BINARY_DIR}")
  message(FATAL_ERROR "
FATAL: In-source builds are not allowed.
       You should create a separate directory for build files.
")
endif()

Building a Library with CMake

Let’s expand the CMakeHello project with additional sub folder and a class.

To keep things simple, we added a template class which is able to do 4 math operations, sum, subtraction, division, multiplication only on integers.

    First, we created lib/math folder inside source tree.
    Then, added class files, operations.cpp, operations.hpp as following

#ifndef CMAKEHELLO_OPERATIONS_HPP
#define CMAKEHELLO_OPERATIONS_HPPnamespace math {
    class operations{
    public:
        int sum(const int &a, const int &b);
        int mult(const int &a, const int &b);
        int div(const int &a, const int &b);
        int sub(const int &a, const int &b);
    };
}#endif //CMAKEHELLO_OPERATIONS_HPP#include <exception>
#include <stdexcept>
#include <iostream>#include "operations.hpp"int math::operations::sum(const int &a, const int &b){
    return a + b;
}int math::operations::mult(const int &a, const int &b){
    return a * b;
}int math::operations::div(const int &a, const int &b){
    if(b == 0){
        throw std::overflow_error("Divide by zero exception");
    }
    return a/b;
}int math::operations::sub(const int &a, const int &b){
    return a - b;
}

    Then, we modified main.cpp to include operations.hpp and use its sum method instead of previously written sum.

#include <iostream>#include "lib/math/operations.hpp"int main() {
	std::cout<<"Hello CMake!"<<std::endl;        math::operations op;        int sum = op.sum(3, 4);	std::cout<<"Sum of 3 + 4 :"<<sum<<std::endl;	return 0;
}

Quick Note: Shared vs Static Library
“Colorful book covers on shelves in a library” by Jamie Taylor on Unsplash

Before going more with library building with C++, lets get a quick brief about shared and static libraries.

Shared Library File Extensions:

    Windows: .dll
    Mac OS X: .dylib
    Linux: .so

Static Library File Extensions:

    Windows: .lib
    Mac OS X: .a
    Linux: .a

Shared libraries are mainly placed in a shared resource of host to make sure multiple applications can access them. Compiler’s build systems with assumption that, shared libraries will be in a shared folder during the execution time so application binary size would reduce, it will handle some of the resources from shared libraries during executions. That requirement also decrease the performance because at each execution it tries to load instructions from shared objects.

Static libraries are used to fetch instructions directly into application binary by compiler, so all the code required from library are already injected into final application binary. That increase the size of object but increase the size of binary but performance get increased. Applications build with static library will also don’t need dependencies on the running platform.
Building Library with Target

If you just want to build these files together with main.cpp, you can just add source files next to add_executable command. This will compile all together and create a single binary file. Leading to 15.076 bytes of exe file.

cmake_minimum_required(VERSION 3.9.1)project(CMakeHello)set(CMAKE_CXX_STANDARD 14)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall")set(EXECUTABLE_OUTPUT_PATH ${CMAKE_BINARY_DIR}/bin)add_executable(cmake_hello main.cpp lib/math/operations.cpp lib/math/operations.hpp)

As an alternate, you can create a variable named ${SOURCES} as a list to include target sources. It can be done in a lot of different ways, depending on your methodology.

cmake_minimum_required(VERSION 3.9.1)project(CMakeHello)set(CMAKE_CXX_STANDARD 14)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall")set(EXECUTABLE_OUTPUT_PATH ${CMAKE_BINARY_DIR}/bin)
set(SOURCES main.cpp 
            lib/math/operations.cpp 
            lib/math/operations.hpp)add_executable(cmake_hello ${SOURCES})

Building Library Separate than Target

We can build library separately either as shared or static.

If we do that, we also need to link library to executable in order to enable executable file to make calls from operations library. We also want to generate library binaries inside lib directory of build folder.

    set LIBRARY_OUTPUT_PATH
    add_library command as SHARED or STATIC
    target_link_libraries to target (cmake_hello)

cmake_minimum_required(VERSION 3.9.1)project(CMakeHello)set(CMAKE_CXX_STANDARD 14)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall")set(EXECUTABLE_OUTPUT_PATH ${CMAKE_BINARY_DIR}/bin)
set(LIBRARY_OUTPUT_PATH  ${CMAKE_BINARY_DIR}/lib)message(${CMAKE_BINARY_DIR})add_library(math SHARED lib/math/operations.cpp)
#add_library(math STATIC lib/math/operations.cpp)add_executable(cmake_hello main.cpp)target_link_libraries(cmake_hello math)

You will see that, in mac OS, libmath.dylib is generated and binary size decreased to 14.876 bytes. (No significant change because code is already very small).
Build Library as Sub-Module CMake

Another library building process is that, you can write a new CMakeLists.txt file inside lib/operations folder, to build it independently just before building exe file.

This kind of situations are mostly needed when there is an optional build required to generate module. In our case, above solution is better since they all dependend. However, if you want to add a case to only build libraries and skipping executable build process, below example can work as well.

Generate a new CMakeLists.txt inside lib/math folder as shown in below code snippet to build library.

cmake_minimum_required(VERSION 3.9.1)set(LIBRARY_OUTPUT_PATH  ${CMAKE_BINARY_DIR}/lib)add_library(math SHARED operations.cpp)

    You should delete add_library command and setting LIBRARY_OUTPUT_PATH from main CMakeLists.txt.
    Now, you should add new build path with add_subdirectoy. This command makes cmake to go for the folder and build it as well with the CMakeLists.txt inside it.

cmake_minimum_required(VERSION 3.9.1)project(CMakeHello)set(CMAKE_CXX_STANDARD 14)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall")set(EXECUTABLE_OUTPUT_PATH ${CMAKE_BINARY_DIR}/bin)message(${CMAKE_BINARY_DIR})add_subdirectory(lib/math)add_executable(cmake_hello main.cpp)target_link_libraries(cmake_hello math)

    Now, you will see the libmath.diylib inside build/lib folder again.

Above, examples shows how to deal with additional sources inside source tree. Either build them all together or separately according to your release plans.
Finding Existing Library with CMake

In most cases, you may require to use installed libraries on your build host. For example, you can install boost library with apt-get or brew package managers to your system.

CMake has conditional statements to allow you to block building process if library is not installed.

If a library installed to system with its .cmake configurations, cmake would be able to look for system default library locations to find that library. like /usr/lib;/usr/local/lib

Boost library can be installed via package managers, brew or apt-get to system. We can use, cmake’s find_package command to check if library exists before building executable.

Let’s change our example little more. I want to use Boost normal distribution library to generate random samples. Therefore, I included boost/random.hpp, and initialized boost::random::normal_distribution to generate numbers with variate_generator.

#include <iostream>#include "lib/math/operations.hpp"#include <boost/random.hpp>int main() {
	std::cout<<"Hello CMake!"<<std::endl;        math::operations op;        int sum = op.sum(3, 4);	std::cout<<"Sum of 3 + 4 :"<<sum<<std::endl;    //Boost Random Sample
    boost::mt19937 rng;
    double mean = 2.3;
    double std = 0.34;
    auto normal_dist = boost::random::normal_distribution<double>(mean, std);    boost::variate_generator<boost::mt19937&,
            boost::normal_distribution<> > random_generator(rng, normal_dist);    for(int i = 0; i < 2; i++){
        auto rand_val = random_generator();
        std::cout<<"Random Val "<<i+1<<" :"<<rand_val<<std::endl;
    }	return 0;
}

How CMakeLists.txt should be written now? It should check for the Boost library, if it can find includes headers and links libraries.

Note: In most cases, default library and include paths are defined in cmake default configurations, so it may find these libraries without any modification, but it is not suggested to leave CMakeLists.txt with trusting to system.

cmake_minimum_required(VERSION 3.9.1)project(CMakeHello)set(CMAKE_CXX_STANDARD 14)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall")#set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)
set(EXECUTABLE_OUTPUT_PATH ${CMAKE_BINARY_DIR}/bin)message(${CMAKE_BINARY_DIR})add_executable(cmake_hello main.cpp)add_subdirectory(lib/math)find_package(Boost 1.66)# Check for libray, if found print message, include dirs and link libraries.
if(Boost_FOUND)
    message("Boost Found")
    include_directories(${Boost_INCLUDE_DIRS})
    target_link_libraries(cmake_hello ${Boost_LIBRARIES})
elseif(NOT Boost_FOUND)
    error("Boost Not Found")
endif()target_link_libraries(cmake_hello math)

include_directories will include library headers, target_link_libraries will link boost library. Above code will not continue to build if package not found since we defined error, but you can also add REQUIRED flag after package to raise error.

Note: Boost name already recognized by system because cmake has already defined commands to check for Boost library. If it is not a common library like boost, you should write your own scripts to enable this feature.

When a package found, following variables will be initialized automatically.

<NAME>_FOUND : Flag to show if it is found
<NAME>_INCLUDE_DIRS or <NAME>_INCLUDES : Header directories
<NAME>_LIBRARIES or <NAME>_LIBRARIES or <NAME>_LIBS : library files
<NAME>_DEFINITIONS

So what happens, if a library is in a custom folder and outside of source tree. If there won’t be any CMake, your command line build would look like below.

g++ main.cpp -o cmake_hello -I/home/onur/libraries/boost/include -L/home/onur/libraries/boost -lBoost

With this logic, you should add include and library folder with following commands.

include_directories(/Users/User/Projects/libraries/include)
link_directories(/Users/User/Projects/libraries/libs)# elseif case can be 
elseif(NOT Boost_FOUND)
message("Boost Not Found")
	include_directories(/Users/User/Projects/libraries/include)
	link_directories(/Users/User/Projects/libraries/libs)
	target_link_libraries(cmake_hello Boost)
endif()

Many different methodologies can be followed while including custom libraries for your project. You can also write custom cmake methods to search for given folders to check libraries etc. Most important thing is to understand linkage logic of compiler. You should point the headers and library (.so, .a) folder and link library for compile process.

Above case is not very safe, because you can’t be sure about if it exists in the folders of host. Safest method is to fetch sources of library and build before going forward. In order to provide this property, dependent library should be added with its sources. If library is closed source, you should include binary to your source tree.

However, it is not always easy to distribute sources because of licensing issues, legal problems etc. It is responsibility of build engineer to figure out best practice for this situation.
Target System Configurations
Photo by Markus Spiske on Unsplash

It is highly possible to build your application, library for or on multiple systems. For example, you may want to include Intel related libraries if you want to deploy your binary on a intel system or you may want to cross-compile for an embedded system, like Android. In order to organise build system, you should add all possible checks into your cmake as well as your code as macros.
Change Compiler and Linker for Build

Let’s say you will cross-compile your project for a different target system. In such cases, your host system should include the target system compiler and linker installed. A basic example is shown in official documentation of CMake: https://cmake.org/cmake/help/v3.6/manual/cmake-toolchains.7.html#cross-compiling-for-linux

Official example is enough for this article’s context, in order to cover it basically. It is an example of building for Raspberry Pi with its C/C++ compiler and tools (linker etc.)

set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR arm)set(CMAKE_SYSROOT /home/devel/rasp-pi-rootfs)
set(CMAKE_STAGING_PREFIX /home/devel/stage)set(tools /home/devel/gcc-4.7-linaro-rpi-gnueabihf)
set(CMAKE_C_COMPILER ${tools}/bin/arm-linux-gnueabihf-gcc)
set(CMAKE_CXX_COMPILER ${tools}/bin/arm-linux-gnueabihf-g++)set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_PACKAGE ONLY)

Most important part is to point compiler and tools (linker) paths correctly. Rest is configuration of build process, including optimisations.

It is also important to know your target system’s compiler properties, it would always be different than the host system. For example, intel system has different level of instructions than ARM. Even arm cpu’s would differ for instruction sets so for optimisations. Make sure you had covered those logic to apply for your cross-compile.

In the next section, we tried to cover some of the basic compiler and linker flags for GNU GCC and Clang.
Compiler/Linker Flags with CMake

Compiler and Linker flags enables engineers to customise behavior of compiler during build process for warnings, optimisations of building process. CMake doesn’t give any new feature additional to flags used by Clang or GNU compilers. But, lets have an overview of compiler and linker flags and what they have been used for.

See, user manuals:

    https://gcc.gnu.org/onlinedocs/gcc-2.95.2/gcc_2.html
    https://clang.llvm.org/docs/ClangCommandLineReference.html

Compiler Flags
Setting Compiler Flags

Compiler flags are crucial when it comes to configure your application’s final properties, optimisation values, behaviour of compiler etc. In Makefile or command line it can be defined in different ways but it is rather easier to define them in CMake. Just like below:

set(CMAKE_CXX_FLAGS "-std=c++0x -Wall")
# suggested way is to keep previous flags in mind and append new ones
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++0x -Wall")# Alternatively, you can use generator expressions, which are conditional expressions. Below says that, if compiper is c++ then set it to c++11
add_compile_options("$<$<STREQUAL:$<TARGET_PROPERTY:LINKER_LANGUAGE>,CXX>:-std=c++11>")

It is quite important to know, how these flags works and what flags do you want to use than setting flags with CMake.

    Optimisation flags set certain compiler flags or disables them. These flags are defined to make easier to switch on/off certain optimisation flags.
    Please see manual:
    https://clang.llvm.org/docs/ClangCommandLineReference.html#optimization-level
    https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

-O0, -O1, -O2, -O3, -Os, -Oz, -Ofast

    Warning flags set warning properties during build process to see any warning during build to report them. Some may be turned off to fasten compile process because each warning process would require to make analysis. See manual and tree.
    https://gist.github.com/d0k/3608547
    https://clang.llvm.org/docs/DiagnosticsReference.html

-Wstring-conversion, -Wall, -Wswitch-enum …
Set Source File Properties

This is a complex property of CMake if there are multiple targets, it can be needed to change one target’s certain behavior. In case, you would like to build main.cpp with C++11 and if you building only library, you may want to build it with C++14. In such cases, you may want to configure certain source’s properties with using set_source_files_properties command like below:

set_source_files_properties(${CMAKE_CURRENT_SOURCE_DIR}/*.cpp PROPERTIES COMPILE_FLAGS "-std=c++11")

A large set of properties can be seen from following manual.

    https://cmake.org/cmake/help/v3.3/manual/cmake-properties.7.html#source-file-properties

Each can be used for a specific case needed for your purpose.
Linker Flags

Here is a list of linker flags of GNU GCC Linker.

    https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html

GCC linker, by default can search the directories defined in environment variables /usr/lib;/usr/local/lib , then links standard libraries by default.

Most common flag is -l to link desired library like, -lzlib, -lboost etc.

Additional flags, help you to change behavior of linking options of executable.

Below are the variables which you can add linker flags.

    CMAKE_EXE_LINKER_FLAGS: Flags used to by linker during creation of executable
    CMAKE_EXE_LINKER_FLAGS_RELEASE: Flags used to by linker during creation of release executable
    CMAKE_EXE_LINKER_FLAGS_DEBUG: Flags used to by linker during creation of debug executable
    CMAKE_STATIC_LINKER_FLAGS: Flags used by linker during the creation of static libraries (.a, .lib)
    CMAKE_SHARED_LINKER_FLAGS: Flags used by linker during the creation of static libraries (.a, .lib)
    CMAKE_MODULE_LINKER_FLAGS: Flags used by linker during the creation of static libraries (.a, .lib)

set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -fsanitize=address")
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -Wl")

Debug and Release Configuration

It is highly recommended to create CMakeLists.txt with multiple configurations according to your needs. If you intend to deliver binaries, you should make a Release, which doesn't include debug flags in binary, which would be a way faster and ready to run. However, debug version of executable files include many of other flags which exposes the memory, method names etc for debuggers to help identify the errors. It is not a good practice and not safe to deliver debug version of an application.

CMake helps you to write script to separate final builds of both type of outputs. There are additional build types like Release with Debug Flags (RELWITHDEBINFO) or Minium Release Size (MINSIZEREL). In this example, we will show both.

    You have to create Debug and Release folders for both type of builds under your build folder. build/Debug and build/Release. cmake command line will change as below:

$ cmake -H. -Bbuild/Debug
$ cmake -H. -Bbuild/Release

    Above configuration is not enough to create different binaries. You should also set build type with CMAKE_BUILD_TYPE variable on the command line. (CLion handles this process by itself.)

$ cmake -DCMAKE_BUILD_TYPE=Debug -H.  -Bbuild/Debug
$ cmake -DCMAKE_BUILD_TYPE=Release -H. -Bbuild/Release

    CMAKE_BUILD_TYPE is accessible inside CMakeLists.txt. You can easily check for build type in CMakeLists.txt

if(${CMAKE_BUILD_TYPE} MATCHES Debug)
    message("Debug Build")
elseif(${CMAKE_BUILD_TYPE} MATCHES Release)
    message("Release Build")
endif()

    You can also, set compiler and linker flags separately for build types using the config variables shown in the previous section.
    CMAKE_EXE_LINKER_FLAGS_RELEASE: Flags used to by linker during creation of release executable
    CMAKE_EXE_LINKER_FLAGS_DEBUG: Flags used to by linker during creation of debug executable
    CMAKE_CXX_FLAGS_RELEASE
    CMAKE_CXX_FLAGS_DEBUG

CMake Installation/Deployment Configurations
Photo by rawpixel on Unsplash

CMake helps create commands for installation process as well, not only the build process.

There is a good coverage of the parameters of install command of CMake in:

    https://cmake.org/cmake/help/v3.0/command/install.html

Main procedure in this process is to copy the files generated by build process to a destination folder on the host. Therefore:

    First, think about destination folder. CMAKE_INSTALL_PREFIX is the variable to define host destination. it is set to /usr/local by default. During the build process, you should point the destination folder in command-line.

$ cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/usr/local/test/with/cmake -H. -Bbuild/Release

    Keeping in mind that, you are getting prefix destination from terminal you should think about library and executable destinations accordingly.

CMake Best Practices

    Always remember the previous configurations, make sure you append new flag instead of overwriting it. It is better to implement, add_flag/remove method of yours, to achieve easier implementation.

set(VARIABLE "${VARIABLE} Flag1 Flag2")

    Always check system information carefully, raise error if a certain configuration can’t be done to prevent faulty binaries.
    Always, check required libraries to continue build process, raise error if not found.

if(Boost_FOUND)
    message("Boost Found")
else()
    error("Boost Not Found")
endif()

Resources
Photo by Patrick Tomasso on Unsplash

    https://cmake.org/cmake-tutorial/
    https://tuannguyen68.gitbooks.io/learning-cmake-a-beginner-s-guide/content/chap1/chap1.html
    https://cmake.org/cmake/help/latest
    https://cmake.org/cmake/help/v3.10/
    https://www.vtk.org/Wiki/CMake/Examples
    https://cmake.org/cmake/help/v3.0/module/FindBoost.html
    https://gcc.gnu.org/onlinedocs/gcc-2.95.2/gcc_2.html
    https://clang.llvm.org/docs/ClangCommandLineReference.html
    http://www.bu.edu/tech/support/research/software-and-programming/programming/compilers/gcc-compiler-flags/

# Header 1
## Header 2
### Header 3
#### Header 4
##### Header 5
###### Header 6
Header 1
=
Header 2
-

*italics* or _italics_

**bold** or __bold__

~~strikethrough~~

* Unordered 1
* Unordered 2
+ Unordered 1
+ Unordered 2
- Unordered 1
- Unordered 2
  - Sublist
    - Subsublist
      - Subsubsublist

1. Ordered 1
1. Ordered 2
1) Ordered 1
1) Ordered 2

First paragraph.
Fake paragraph.  
New paragraph without an extra lilne after 2 spaces.

New paragraph with an extra line after 2 enters.

   Intended paragraph after 2 spaces.  
   New Intended paragraph.
   
     More intended paragraph.
     New more intended paragraph.

      Even more intended paragraph.
      New even more intended paragraph.

> Blockquotes.  
> This line is part of the same quote.

> This is new quote.

---

___

***

[Inline-style link](https://www.google.com)

[Inline-style link with title](https://www.google.com "Google")

[Inline-style link to a repository file](../folder/folder/file.txt)

[Reference-style link with a word reference][Reference]

[Reference-style link with a number][1]

Reference-style link with separate URL [this is the link]

Here's a sentence with a footnote. [^1]

[^1]: This is the footnote.

Raw URL turned into link - without brackets: https://www.google.com, 
with brackets: <https://www.google.com> 

[Reference]: https://www.mozilla.org
[1]: http://slashdot.org
[this is the link]: http://www.reddit.com

Inline-style image: 
![alternative text](https://github.com/adam-p/markdown-here/raw/master/src/common/images/icon48.png "Logo Title Text 1")

Reference-style image
![alternative text][logo]

[logo]: https://github.com/adam-p/markdown-here/raw/master/src/common/images/icon48.png "Logo Title Text 2"

In-line `code` inside back-ticks.

Block of codes inside triple back-ticks.
```
var x = "abc";
```

Block of code with a specific language
```py
x = [1, 2, 3]
```

Markdown | Less | Pretty
--- | --- | ---
*Still* | `renders` | **nicely**
1 | 2 | 3

| Tables        | Are           | Cool  |
| ------------- |:-------------:| -----:|
| col 3 is      | right-aligned | $1600 |
| col 2 is      | centered      |   $12 |
| zebra stripes | are neat      |    $1 |

<dl>
  <dt>Definition list</dt>
  <dd>Is something people use sometimes.</dd>

  <dt>Markdown in HTML</dt>
  <dd>Does *not* work **very** well. Use HTML <em>tags</em>.</dd>
</dl>

[![IMAGE ALT TEXT HERE](http://img.youtube.com/vi/YOUTUBE_VIDEO_ID_HERE/0.jpg)](http://www.youtube.com/watch?v=YOUTUBE_VIDEO_ID_HERE)

<a href="http://www.youtube.com/watch?feature=player_embedded&v=YOUTUBE_VIDEO_ID_HERE
" target="_blank"><img src="http://img.youtube.com/vi/YOUTUBE_VIDEO_ID_HERE/0.jpg" 
alt="IMAGE ALT TEXT HERE" width="240" height="180" border="10" /></a>

* [ ] a task 
- [x] a task

1. Click the Start menu.

2. Click Run or in the search bar type services.msc.

3. Press Enter.

4. Look for the service and check the Properties and identify its service name.

5. Once found, open a command prompt type 
	```type	
	sc queryex [servicename]
	```
6. Press Enter.

7. Identify the PID.

8. In the same command prompt type
	
	```type 
		taskkill /pid [pid number] /f
	```
9. Press Enter.

git tag 1.0.2
git push --tags