code:
defmodule Qtfile.RoomsTest do
  use Qtfile.DataCase

  alias Qtfile.Rooms

  describe "rooms" do
    alias Qtfile.Rooms.Room

    @valid_attrs %{disabled: true, file_ttl: 42, files: "some files", motd: "some motd", owner: "some owner", room_id: "some room_id", room_name: "some room_name"}
    @update_attrs %{disabled: false, file_ttl: 43, files: "some updated files", motd: "some updated motd", owner: "some updated owner", room_id: "some updated room_id", room_name: "some updated room_name"}
    @invalid_attrs %{disabled: nil, file_ttl: nil, files: nil, motd: nil, owner: nil, room_id: nil, room_name: nil}

    def room_fixture(attrs \\ %{}) do
      {:ok, room} =
        attrs
        |> Enum.into(@valid_attrs)
        |> Rooms.create_room()

      room
    end

    test "list_rooms/0 returns all rooms" do
      room = room_fixture()
      assert Rooms.list_rooms() == [room]
    end

    test "get_room!/1 returns the room with given id" do
      room = room_fixture()
      assert Rooms.get_room!(room.id) == room
    end

    test "create_room/1 with valid data creates a room" do
      assert {:ok, %Room{} = room} = Rooms.create_room(@valid_attrs)
      assert room.disabled == true
      assert room.file_ttl == 42
      assert room.files == "some files"
      assert room.motd == "some motd"
      assert room.owner == "some owner"
      assert room.room_id == "some room_id"
      assert room.room_name == "some room_name"
    end

    test "create_room/1 with invalid data returns error changeset" do
      assert {:error, %Ecto.Changeset{}} = Rooms.create_room(@invalid_attrs)
    end

    test "update_room/2 with valid data updates the room" do
      room = room_fixture()
      assert {:ok, room} = Rooms.update_room(room, @update_attrs)
      assert %Room{} = room
      assert room.disabled == false
      assert room.file_ttl == 43
      assert room.files == "some updated files"
      assert room.motd == "some updated motd"
      assert room.owner == "some updated owner"
      assert room.room_id == "some updated room_id"
      assert room.room_name == "some updated room_name"
    end

    test "update_room/2 with invalid data returns error changeset" do
      room = room_fixture()
      assert {:error, %Ecto.Changeset{}} = Rooms.update_room(room, @invalid_attrs)
      assert room == Rooms.get_room!(room.id)
    end

    test "delete_room/1 deletes the room" do
      room = room_fixture()
      assert {:ok, %Room{}} = Rooms.delete_room(room)
      assert_raise Ecto.NoResultsError, fn -> Rooms.get_room!(room.id) end
    end

    test "change_room/1 returns a room changeset" do
      room = room_fixture()
      assert %Ecto.Changeset{} = Rooms.change_room(room)
    end
  end
end


code:
defmodule Qtfile.SingleTokenTest do
  use Qtfile.DataCase

  alias Qtfile.SingleToken

  describe "tokens" do
    alias Qtfile.SingleToken.Token

    @valid_attrs %{token: "some token"}
    @update_attrs %{token: "some updated token"}
    @invalid_attrs %{token: nil}

    def token_fixture(attrs \\ %{}) do
      {:ok, token} =
        attrs
        |> Enum.into(@valid_attrs)
        |> SingleToken.create_token()

      token
    end

    test "list_tokens/0 returns all tokens" do
      token = token_fixture()
      assert SingleToken.list_tokens() == [token]
    end

    test "get_token!/1 returns the token with given id" do
      token = token_fixture()
      assert SingleToken.get_token!(token.id) == token
    end

    test "create_token/1 with valid data creates a token" do
      assert {:ok, %Token{} = token} = SingleToken.create_token(@valid_attrs)
      assert token.token == "some token"
    end

    test "create_token/1 with invalid data returns error changeset" do
      assert {:error, %Ecto.Changeset{}} = SingleToken.create_token(@invalid_attrs)
    end

    test "update_token/2 with valid data updates the token" do
      token = token_fixture()
      assert {:ok, token} = SingleToken.update_token(token, @update_attrs)
      assert %Token{} = token
      assert token.token == "some updated token"
    end

    test "update_token/2 with invalid data returns error changeset" do
      token = token_fixture()
      assert {:error, %Ecto.Changeset{}} = SingleToken.update_token(token, @invalid_attrs)
      assert token == SingleToken.get_token!(token.id)
    end

    test "delete_token/1 deletes the token" do
      token = token_fixture()
      assert {:ok, %Token{}} = SingleToken.delete_token(token)
      assert_raise Ecto.NoResultsError, fn -> SingleToken.get_token!(token.id) end
    end

    test "change_token/1 returns a token changeset" do
      token = token_fixture()
      assert %Ecto.Changeset{} = SingleToken.change_token(token)
    end
  end
end

repo_name: bye/ass

license: mit


code:
defmodule QtfileWeb.PageControllerTest do
  use QtfileWeb.ConnCase

  test "GET /", %{conn: conn} do
    conn = get conn, "/"
    assert html_response(conn, 200) =~ "Welcome to Phoenix!"
  end
end


code:
defmodule QtfileWeb.ErrorViewTest do
  use QtfileWeb.ConnCase, async: true

  # Bring render/3 and render_to_string/3 for testing custom views
  import Phoenix.View

  test "renders 404.html" do
    assert render_to_string(QtfileWeb.ErrorView, "404.html", []) ==
           "Page not found"
  end

  test "render 500.html" do
    assert render_to_string(QtfileWeb.ErrorView, "500.html", []) ==
           "Internal server error"
  end

  test "render any other" do
    assert render_to_string(QtfileWeb.ErrorView, "505.html", []) ==
           "Internal server error"
  end
end


code:
defmodule QtfileWeb.LayoutViewTest do
  use QtfileWeb.ConnCase, async: true
end


code:
defmodule QtfileWeb.PageViewTest do
  use QtfileWeb.ConnCase, async: true
end


code:
defmodule QtfileWeb.ChannelCase do
  @moduledoc """
  This module defines the test case to be used by
  channel tests.

  Such tests rely on `Phoenix.ChannelTest` and also
  import other functionality to make it easier
  to build common datastructures and query the data layer.

  Finally, if the test case interacts with the database,
  it cannot be async. For this reason, every test runs
  inside a transaction which is reset at the beginning
  of the test unless the test case is marked as async.
  """

  use ExUnit.CaseTemplate

  using do
    quote do
      # Import conveniences for testing with channels
      use Phoenix.ChannelTest

      # The default endpoint for testing
      @endpoint QtfileWeb.Endpoint
    end
  end

  setup tags do
    :ok = Ecto.Adapters.SQL.Sandbox.checkout(Qtfile.Repo)
    unless tags[:async] do
      Ecto.Adapters.SQL.Sandbox.mode(Qtfile.Repo, {:shared, self()})
    end
    :ok
  end

end


code:
defmodule QtfileWeb.ConnCase do
  @moduledoc """
  This module defines the test case to be used by
  tests that require setting up a connection.

  Such tests rely on `Phoenix.ConnTest` and also
  import other functionality to make it easier
  to build common datastructures and query the data layer.

  Finally, if the test case interacts with the database,
  it cannot be async. For this reason, every test runs
  inside a transaction which is reset at the beginning
  of the test unless the test case is marked as async.
  """

  use ExUnit.CaseTemplate

  using do
    quote do
      # Import conveniences for testing with connections
      use Phoenix.ConnTest
      import QtfileWeb.Router.Helpers

      # The default endpoint for testing
      @endpoint QtfileWeb.Endpoint
    end
  end

  setup tags do
    :ok = Ecto.Adapters.SQL.Sandbox.checkout(Qtfile.Repo)
    unless tags[:async] do
      Ecto.Adapters.SQL.Sandbox.mode(Qtfile.Repo, {:shared, self()})
    end
    {:ok, conn: Phoenix.ConnTest.build_conn()}
  end

end


code:
defmodule Qtfile.DataCase do
  @moduledoc """
  This module defines the setup for tests requiring
  access to the application's data layer.

  You may define functions here to be used as helpers in
  your tests.

  Finally, if the test case interacts with the database,
  it cannot be async. For this reason, every test runs
  inside a transaction which is reset at the beginning
  of the test unless the test case is marked as async.
  """

  use ExUnit.CaseTemplate

  using do
    quote do
      alias Qtfile.Repo

      import Ecto
      import Ecto.Changeset
      import Ecto.Query
      import Qtfile.DataCase
    end
  end

  setup tags do
    :ok = Ecto.Adapters.SQL.Sandbox.checkout(Qtfile.Repo)

    unless tags[:async] do
      Ecto.Adapters.SQL.Sandbox.mode(Qtfile.Repo, {:shared, self()})
    end

    :ok
  end

  @doc """
  A helper that transform changeset errors to a map of messages.

      assert {:error, changeset} = Accounts.create_user(%{password: "short"})
      assert "password is too short" in errors_on(changeset).password
      assert %{password: ["password is too short"]} = errors_on(changeset)

  """
  def errors_on(changeset) do
    Ecto.Changeset.traverse_errors(changeset, fn {message, opts} ->
      Enum.reduce(opts, message, fn {key, value}, acc ->
        String.replace(acc, "%{#{key}}", to_string(value))
      end)
    end)
  end
end


code:
ExUnit.start()

Ecto.Adapters.SQL.Sandbox.mode(Qtfile.Repo, :manual)


code:
.DS_Store
Makefile
CMakeCache.txt
CMakeFiles
cmake_install.cmake
.cmake/
config.py
craft
!craft/
server
!server/
world
!world/
env
gt
.idea
CMakeDoxyfile.in
CMakeDoxygenDefaults.cmake
Testing/
*.cbp
log.txt
*.o
*.db
*.exe
*.dll
!libcurl.dll
*.pyc
cmake_uninstall.cmake
glfw3.pc
glfw3Config.cmake
glfw3ConfigVersion.cmake
glfw_config.h
libglfw3.a
build/
git_env.bat
*.exp
*.ilk
craft.lib
*.pdb
deps/glfw/src/glfw3.lib
server.lib
deps/qoi/build/
*.a
cmake_build_files/

repo_name: lazytadpole/codenamesilverfish

path: .gitignore


code:
cmake_minimum_required(VERSION 3.10)

project(craft)

SET(ENV{LSAN_OPTIONS} "suppressions=sup.txt")
if (LINUX)
    add_compile_options(-fsanitize=leak,address)
    add_link_options(-fsanitize=leak,address)
    ##add_compile_options(-fsanitize=thread)
    ##add_link_options(-fsanitize=thread)
    add_compile_options(-ggdb)
    add_link_options(-ggdb)
endif()

add_definitions(-DENABLE_CJSON_UTILS=On -DENABLE_CJSON_TEST=Off)
add_definitions(-DLOG_USE_COLOR)

if (UNIX)
    add_definitions(-DUNIX)
endif()

if (WIN32 OR WIN64)
    add_definitions(-DWINDOWS)
endif()

if (APPLE)
    add_definitions(-DAPPLE)
endif()

FILE(GLOB SOURCE_FILES src/*.c)

FILE(GLOB COMMON_SOURCE_FILES
    src/common/common.c
    src/common/config.c
    src/common/qoi_utils.c

    src/common/util/itoa.c
    src/common/util/ltoa.c
    src/common/util/ulltoa.c
    src/common/util/pointer_util.c
    src/common/util/min_max.c
    src/common/util/windows_console_helper.c
    src/common/util/vec_util.c
    src/common/util/file_util.c
    src/common/util/ftoa.c
    src/common/util/json_util.c
    src/common/util/string_util.c
)

FILE(GLOB SERVER_SOURCE_FILES
    src/server/server.c
    src/server/config_main.c

    src/server/util/shutdown.c
)

FILE(GLOB CLIENT_SOURCE_FILES
    src/client/network.c
    src/client/world_interact.c
    src/client/chat.c

    src/client/util/shutdown.c
)

FILE(GLOB COMMON_DEPS
    deps/lodepng/lodepng.c # needed for server-side image validation for skin upload
    deps/noise/noise.c
    deps/sqlite/sqlite3.c
    deps/tinycthread/tinycthread.c
    deps/cJSON/cJSON.c
    deps/qoi/qoi.c
    deps/log.c/log.c
    deps/c-vector/vec.c
)

# This needs to happen before add_executable or add_library
if(MINGW)
    link_directories(${CMAKE_CURRENT_LIST_DIR}/deps/curl_windows_mingw/lib)
endif()

add_executable(
    craft

    ${SOURCE_FILES}
    ${CLIENT_SOURCE_FILES}
    ${COMMON_SOURCE_FILES}
    ${COMMON_DEPS}
    deps/glew/src/glew.c
)

add_executable(
    server

    src/world.c
    ${COMMON_SOURCE_FILES}
    ${SERVER_SOURCE_FILES}
    ${COMMON_DEPS}
)

# Used by the logger
target_compile_definitions(craft PUBLIC NET_SIDE_SYMBOL="CLIENT")
target_compile_definitions(server PUBLIC NET_SIDE_SYMBOL="SERVER")

add_definitions(-std=gnu99) #-O3)

set(GLFW_BUILD_DOCS OFF CACHE BOOL "" FORCE)
set(GLFW_BUILD_TESTS OFF CACHE BOOL "" FORCE)
set(GLFW_BUILD_EXAMPLES OFF CACHE BOOL "" FORCE)

add_subdirectory(deps/glfw)
add_subdirectory(deps/cwalk)

include_directories(src/headers)
include_directories(deps/glew/include)
include_directories(deps/glfw/include)
include_directories(deps/lodepng)
include_directories(deps/noise)
include_directories(deps/sqlite)
include_directories(deps/tinycthread)
include_directories(deps/cJSON)
include_directories(deps/cwalk/include)
include_directories(deps/qoi)
include_directories(deps/stb)
include_directories(deps/log.c)
include_directories(deps/klib)
include_directories(deps/c-vector)

#TODO: Link necessary libraries for target 'server' (it doesn't link to graphics at all (except image manipulation libs))
target_link_libraries(craft cwalk m)
target_link_libraries(server cwalk m)

if(WIN32 AND NOT MINGW)
    set(CURL_INCLUDE_DIR "deps/curl_windows/include")
    set(CURL_LIBRARY "deps/curl_windows/lib/libcurl")
endif()

if(MINGW)
    add_definitions(-DCURL_STATICLIB)
    set(CURL_LIBRARY "${CMAKE_CURRENT_LIST_DIR}/deps/curl_windows_mingw/lib/libcurl.a")
    set(CURL_INCLUDE_DIR "${CMAKE_CURRENT_LIST_DIR}/deps/curl_windows_mingw/include")
endif()

find_package(CURL REQUIRED)
include_directories(${CURL_INCLUDE_DIR})

if(APPLE)
    target_link_libraries(craft glfw
        ${GLFW_LIBRARIES} ${CURL_LIBRARIES})
endif()

if(UNIX)
    target_link_libraries(craft dl glfw GL
        ${GLFW_LIBRARIES} ${CURL_LIBRARIES})
endif()

if(MINGW)
    #target_link_libraries(craft ${CURL_LIBRARIES}
    #    ws2_32.lib wldap32.lib advapi32.lib kernel32.lib comdlg32.lib crypt32.lib normaliz.lib glfw opengl32
    #    ${GLFW_LIBRARIES})

    target_link_libraries(craft

        brotlicommon brotlidec crypto curl nghttp2 nghttp3 ngtcp2 ngtcp2_crypto_quictls psl ssh2 ssl z zstd

        ws2_32 wldap32 advapi32 kernel32 comdlg32 crypt32 normaliz glfw opengl32

        ${GLFW_LIBRARIES})
endif()

if(WIN32)
    target_link_libraries(craft ${CURL_LIBRARIES} ws2_32.lib wldap32.lib advapi32.lib kernel32.lib comdlg32.lib crypt32.lib normaliz.lib glfw opengl32 ${GLFW_LIBRARIES})
endif()


code:
* logging to file. should be able to pickup logpath and logname from command line args, otherwise determine one or both automatically
* split code in client / common / server. force client to connect to an existing server, no integrated server bullshit
* feature parity with whatever recent minecraft but focus on 1.7.10
* find ways to optimize saves, maybe sqlite is not the best thing, idk
* lod
* shader support, maybe add a translation layer to classic optifine shaders
* possibility of self-hosted standalone account management service, (as well as possibility to host one directly on a server, might be more hassle than just standalone)
* standard and extended resource pack support
* find elegant way to enable pure C mod modules or maybe say fuck it and consolidate some kind of gt:nh behemoth in C
* Ambient occlusion;And tinted sides on blocks;And fake lights on hand held items
* find some nice solution for gui. I feel like it's either full spartan à la minecraft or something html/css shit (https://mikke89.github.io/RmlUiDoc, https://github.com/litehtml/litehtml)
* tick any visited sleeping chunks with entities inside periodically. make the tick speed faster there so they catch up. simplify whatever possible (e.g. mob behavior/movement)
* some smart way of implementing cubic chunks. periodical chunk wakes should propagate lighting and maybe a fake ceiling?? there should be some heuristics to determine when the player falls to load more chunks below at a time
* prints should probably be protected by a mutex (logs are now, it should be sufficient)
* list of potentially useful pull requests to log.c:
    * https://github.com/rxi/log.c/pull/27/files
    * https://github.com/rxi/log.c/pull/34/files
    * https://github.com/rxi/log.c/pull/25/files
    * https://github.com/rxi/log.c/pull/24/files
    * https://github.com/rxi/log.c/pull/21/files

* list of future libs to include:
    * file dialog: https://github.com/rxi/sfd
    * microui: https://github.com/rxi/microui (web demo: https://floooh.github.io/sokol-html5/sgl-microui-sapp.html)
    * http server: https://github.com/rxi/sandbird # tbh nah, the auth server will be its own thing (in python lol), and dedicated server auth will be over protobuf
    * uuid 4: https://github.com/rxi/uuid4
    * vector: https://github.com/rxi/vec  or  https://github.com/eteran/c-vector (actively maintained)
    * hashmap: https://github.com/rxi/map or https://github.com/Mashpoe/c-hashmap
    * pango or harfbuzz for glyphs
    * maybe gio (gnome i/o) for files
    * protobuf for networking: https://github.com/protobuf-c/protobuf-c

* lib maybeboard
    * subprocesses: https://github.com/sheredom/subprocess.h

* opt
    * tick different things at different rates? Heard might be aids to sync but tbh idk
    * discrete subsystems (a subsystem is notified only if an event concerns it)

* misc of misc
    * blood moon event from random things (?) is related to blood magic


code:
cmake -G "NMake Makefiles" -S . -B .
nmake
:: cd ..
:: "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.37.32822\bin\Hostx86\x86\link.exe" /nologo @CMakeFiles\craft.dir\objects1.rsp /out:craft.exe /implib:craft.lib /pdb:craft.pdb /version:0.0 /machine:X86 /debug /INCREMENTAL /subsystem:console deps/curl_windows/lib/libcurl.lib Ws2_32.lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib opengl32.lib deps/glfw/src/glfw3.lib /MANIFEST /MANIFESTFILE:CMakeFiles\craft.dir/intermediate.manifest CMakeFiles\craft.dir/manifest.res


code:
#echo "==[ Creating  ]=="
mkdir -p cmake_build_files
cmake -S . -B cmake_build_files
cd cmake_build_files
make
cd ..
mkdir -p build
cp cmake_build_files/craft build
#cp cmake_build_files/craft .
echo "copying server..."
cp cmake_build_files/server build
cp -r textures build
cp -r shaders build


code:
rm -r -force build
mkdir build
cp deps\curl_windows_mingw\libcurl-x64.dll build
Copy-Item shaders -Destination build -Recurse
Copy-Item textures -Destination build -Recurse
.\buildtools\windows\cmake\bin\cmake.exe -B build -S . -G "MinGW Makefiles" --toolchain=mingw64-toolchain.cmake
cd build
.\..\buildtools\windows\mingw64\bin\mingw32-make.exe


code:
#!/bin/sh

gcc -std=c99 -O3 -Wall -Wextra -Werror -pedantic -o server -I src -I src/headers -I deps/noise deps/noise/noise.c -I deps/cJSON src/world.c src/server/server.c src/server/config_main.c src/common/common.c src/common/logging.c


code:
# This file allows you to programmatically create blocks in Craft.
# Please use this wisely. Test on your own server first. Do not abuse it.

import requests
import socket
import sqlite3
import sys

DEFAULT_HOST = '127.0.0.1'
DEFAULT_PORT = 4080

EMPTY = 0
GRASS = 1
SAND = 2
STONE = 3
BRICK = 4
WOOD = 5
CEMENT = 6
DIRT = 7
PLANK = 8
SNOW = 9
GLASS = 10
COBBLE = 11
LIGHT_STONE = 12
DARK_STONE = 13
CHEST = 14
LEAVES = 15
CLOUD = 16
TALL_GRASS = 17
YELLOW_FLOWER = 18
RED_FLOWER = 19
PURPLE_FLOWER = 20
SUN_FLOWER = 21
WHITE_FLOWER = 22
BLUE_FLOWER = 23

OFFSETS = [
    (-0.5, -0.5, -0.5),
    (-0.5, -0.5, 0.5),
    (-0.5, 0.5, -0.5),
    (-0.5, 0.5, 0.5),
    (0.5, -0.5, -0.5),
    (0.5, -0.5, 0.5),
    (0.5, 0.5, -0.5),
    (0.5, 0.5, 0.5),
]

def sphere(cx, cy, cz, r, fill=False, fx=False, fy=False, fz=False):
    result = set()
    for x in range(cx - r, cx + r + 1):
        if fx and x != cx:
            continue
        for y in range(cy - r, cy + r + 1):
            # if y < cy:
            #     continue # top hemisphere only
            if fy and y != cy:
                continue
            for z in range(cz - r, cz + r + 1):
                if fz and z != cz:
                    continue
                inside = False
                outside = fill
                for dx, dy, dz in OFFSETS:
                    ox, oy, oz = x + dx, y + dy, z + dz
                    d2 = (ox - cx) ** 2 + (oy - cy) ** 2 + (oz - cz) ** 2
                    d = d2 ** 0.5
                    if d < r:
                        inside = True
                    else:
                        outside = True
                if inside and outside:
                    result.add((x, y, z))
    return result

def circle_x(x, y, z, r, fill=False):
    return sphere(x, y, z, r, fill, fx=True)

def circle_y(x, y, z, r, fill=False):
    return sphere(x, y, z, r, fill, fy=True)

def circle_z(x, y, z, r, fill=False):
    return sphere(x, y, z, r, fill, fz=True)

def cylinder_x(x1, x2, y, z, r, fill=False):
    x1, x2 = sorted((x1, x2))
    result = set()
    for x in range(x1, x2 + 1):
        result |= circle_x(x, y, z, r, fill)
    return result

def cylinder_y(x, y1, y2, z, r, fill=False):
    y1, y2 = sorted((y1, y2))
    result = set()
    for y in range(y1, y2 + 1):
        result |= circle_y(x, y, z, r, fill)
    return result

def cylinder_z(x, y, z1, z2, r, fill=False):
    z1, z2 = sorted((z1, z2))
    result = set()
    for z in range(z1, z2 + 1):
        result |= circle_z(x, y, z, r, fill)
    return result

def cuboid(x1, x2, y1, y2, z1, z2, fill=True):
    x1, x2 = sorted((x1, x2))
    y1, y2 = sorted((y1, y2))
    z1, z2 = sorted((z1, z2))
    result = set()
    a = (x1 == x2) + (y1 == y2) + (z1 == z2)
    for x in range(x1, x2 + 1):
        for y in range(y1, y2 + 1):
            for z in range(z1, z2 + 1):
                n = 0
                n += x in (x1, x2)
                n += y in (y1, y2)
                n += z in (z1, z2)
                if not fill and n <= a:
                    continue
                result.add((x, y, z))
    return result

def pyramid(x1, x2, y, z1, z2, fill=False):
    x1, x2 = sorted((x1, x2))
    z1, z2 = sorted((z1, z2))
    result = set()
    while x2 >= x1 and z2 >= z2:
        result |= cuboid(x1, x2, y, y, z1, z2, fill)
        y, x1, x2, z1, z2 = y + 1, x1 + 1, x2 - 1, z1 + 1, z2 - 1
    return result

def get_identity():
    query = (
        'select username, token from identity_token where selected = 1;'
    )
    conn = sqlite3.connect('auth.db')
    rows = conn.execute(query)
    for row in rows:
        return row
    raise Exception('No identities found.')

class Client(object):
    def __init__(self, host, port):
        self.conn = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        self.conn.connect((host, port))
        self.authenticate()
    def authenticate(self):
        username, identity_token = get_identity()
        url = 'https://craft.michaelfogleman.com/api/1/identity'
        payload = {
            'username': username,
            'identity_token': identity_token,
        }
        response = requests.post(url, data=payload)
        if response.status_code == 200 and response.text.isalnum():
            access_token = response.text
            self.conn.sendall('A,%s,%s\n' % (username, access_token))
        else:
            raise Exception('Failed to authenticate.')
    def set_block(self, x, y, z, w):
        self.conn.sendall('B,%d,%d,%d,%d\n' % (x, y, z, w))
    def set_blocks(self, blocks, w):
        key = lambda block: (block[1], block[0], block[2])
        for x, y, z in sorted(blocks, key=key):
            self.set_block(x, y, z, w)
    def bitmap(self, sx, sy, sz, d1, d2, data, lookup):
        x, y, z = sx, sy, sz
        dx1, dy1, dz1 = d1
        dx2, dy2, dz2 = d2
        for row in data:
            x = sx if dx1 else x
            y = sy if dy1 else y
            z = sz if dz1 else z
            for c in row:
                w = lookup.get(c)
                if w is not None:
                    self.set_block(x, y, z, w)
                x, y, z = x + dx1, y + dy1, z + dz1
            x, y, z = x + dx2, y + dy2, z + dz2

def get_client():
    default_args = [DEFAULT_HOST, DEFAULT_PORT]
    args = sys.argv[1:] + [None] * len(default_args)
    host, port = [a or b for a, b in zip(args, default_args)]
    client = Client(host, int(port))
    return client

def main():
    client = get_client()
    set_block = client.set_block
    set_blocks = client.set_blocks
    # set_blocks(circle_y(0, 32, 0, 16, True), STONE)
    # set_blocks(circle_y(0, 33, 0, 16), BRICK)
    # set_blocks(cuboid(-1, 1, 1, 31, -1, 1), CEMENT)
    # set_blocks(cuboid(-1024, 1024, 32, 32, -3, 3), STONE)
    # set_blocks(cuboid(-3, 3, 32, 32, -1024, 1024), STONE)
    # set_blocks(cuboid(-1024, 1024, 33, 33, -3, -3), BRICK)
    # set_blocks(cuboid(-1024, 1024, 33, 33, 3, 3), BRICK)
    # set_blocks(cuboid(-3, -3, 33, 33, -1024, 1024), BRICK)
    # set_blocks(cuboid(3, 3, 33, 33, -1024, 1024), BRICK)
    # set_blocks(sphere(0, 32, 0, 16), GLASS)
    # for y in range(1, 32):
    #     set_blocks(circle_y(0, y, 0, 4, True), CEMENT)
    # set_blocks(circle_x(16, 33, 0, 3), BRICK)
    # set_blocks(circle_x(-16, 33, 0, 3), BRICK)
    # set_blocks(circle_z(0, 33, 16, 3), BRICK)
    # set_blocks(circle_z(0, 33, -16, 3), BRICK)
    # for x in range(0, 1024, 32):
    #     set_blocks(cuboid(x - 1, x + 1, 31, 32, -1, 1), CEMENT)
    #     set_blocks(cuboid(-x - 1, -x + 1, 31, 32, -1, 1), CEMENT)
    #     set_blocks(cuboid(x, x, 1, 32, -1, 1), CEMENT)
    #     set_blocks(cuboid(-x, -x, 1, 32, -1, 1), CEMENT)
    # for z in range(0, 1024, 32):
    #     set_blocks(cuboid(-1, 1, 31, 32, z - 1, z + 1), CEMENT)
    #     set_blocks(cuboid(-1, 1, 31, 32, -z - 1, -z + 1), CEMENT)
    #     set_blocks(cuboid(-1, 1, 1, 32, z, z), CEMENT)
    #     set_blocks(cuboid(-1, 1, 1, 32, -z, -z), CEMENT)
    # for x in range(0, 1024, 8):
    #     set_block(x, 32, 0, CEMENT)
    #     set_block(-x, 32, 0, CEMENT)
    # for z in range(0, 1024, 8):
    #     set_block(0, 32, z, CEMENT)
    #     set_block(0, 32, -z, CEMENT)
    # set_blocks(pyramid(32, 32+64-1, 12, 32, 32+64-1), COBBLE)
    # outer = circle_y(0, 11, 0, 176 + 3, True)
    # inner = circle_y(0, 11, 0, 176 - 3, True)
    # set_blocks(outer - inner, STONE)
    # a = sphere(-32, 48, -32, 24, True)
    # b = sphere(-24, 40, -24, 24, True)
    # set_blocks(a - b, PLANK)
    # set_blocks(cylinder_x(-64, 64, 32, 0, 8), STONE)
    # data = [
    #     '...............................',
    #     '..xxx..xxxx...xxx..xxxxx.xxxxx.',
    #     '.x...x.x...x.x...x.x.......x...',
    #     '.x.....xxxx..xxxxx.xxx.....x...',
    #     '.x...x.x..x..x...x.x.......x...',
    #     '..xxx..x...x.x...x.x.......x...',
    #     '...............................',
    # ]
    # lookup = {
    #     'x': STONE,
    #     '.': PLANK,
    # }
    # client.bitmap(0, 32, 32, (1, 0, 0), (0, -1, 0), data, lookup)

if __name__ == '__main__':
    main()


code:
CMake - Cross Platform Makefile Generator
Copyright 2000-2024 Kitware, Inc. and Contributors
All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:

* Redistributions of source code must retain the above copyright
  notice, this list of conditions and the following disclaimer.

* Redistributions in binary form must reproduce the above copyright
  notice, this list of conditions and the following disclaimer in the
  documentation and/or other materials provided with the distribution.

* Neither the name of Kitware, Inc. nor the names of Contributors
  may be used to endorse or promote products derived from this
  software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

------------------------------------------------------------------------------

The following individuals and institutions are among the Contributors:

* Aaron C. Meadows <cmake@shadowguarddev.com>
* Adriaan de Groot <groot@kde.org>
* Aleksey Avdeev <solo@altlinux.ru>
* Alexander Neundorf <neundorf@kde.org>
* Alexander Smorkalov <alexander.smorkalov@itseez.com>
* Alexey Sokolov <sokolov@google.com>
* Alex Merry <alex.merry@kde.org>
* Alex Turbov <i.zaufi@gmail.com>
* Andreas Pakulat <apaku@gmx.de>
* Andreas Schneider <asn@cryptomilk.org>
* André Rigland Brodtkorb <Andre.Brodtkorb@ifi.uio.no>
* Axel Huebl, Helmholtz-Zentrum Dresden - Rossendorf
* Benjamin Eikel
* Bjoern Ricks <bjoern.ricks@gmail.com>
* Brad Hards <bradh@kde.org>
* Christopher Harvey
* Christoph Grüninger <foss@grueninger.de>
* Clement Creusot <creusot@cs.york.ac.uk>
* Daniel Blezek <blezek@gmail.com>
* Daniel Pfeifer <daniel@pfeifer-mail.de>
* Dawid Wróbel <me@dawidwrobel.com>
* Enrico Scholz <enrico.scholz@informatik.tu-chemnitz.de>
* Eran Ifrah <eran.ifrah@gmail.com>
* Esben Mose Hansen, Ange Optimization ApS
* Geoffrey Viola <geoffrey.viola@asirobots.com>
* Google Inc
* Gregor Jasny
* Helio Chissini de Castro <helio@kde.org>
* Ilya Lavrenov <ilya.lavrenov@itseez.com>
* Insight Software Consortium <insightsoftwareconsortium.org>
* Intel Corporation <www.intel.com>
* Jan Woetzel
* Jordan Williams <jordan@jwillikers.com>
* Julien Schueller
* Kelly Thompson <kgt@lanl.gov>
* Konstantin Podsvirov <konstantin@podsvirov.pro>
* Laurent Montel <montel@kde.org>
* Mario Bensi <mbensi@ipsquad.net>
* Martin Gräßlin <mgraesslin@kde.org>
* Mathieu Malaterre <mathieu.malaterre@gmail.com>
* Matthaeus G. Chajdas
* Matthias Kretz <kretz@kde.org>
* Matthias Maennich <matthias@maennich.net>
* Michael Hirsch, Ph.D. <www.scivision.co>
* Michael Stürmer
* Miguel A. Figueroa-Villanueva
* Mike Durso <rbprogrammer@gmail.com>
* Mike Jackson
* Mike McQuaid <mike@mikemcquaid.com>
* Nicolas Bock <nicolasbock@gmail.com>
* Nicolas Despres <nicolas.despres@gmail.com>
* Nikita Krupen'ko <krnekit@gmail.com>
* NVIDIA Corporation <www.nvidia.com>
* OpenGamma Ltd. <opengamma.com>
* Patrick Stotko <stotko@cs.uni-bonn.de>
* Per Øyvind Karlsen <peroyvind@mandriva.org>
* Peter Collingbourne <peter@pcc.me.uk>
* Petr Gotthard <gotthard@honeywell.com>
* Philip Lowman <philip@yhbt.com>
* Philippe Proulx <pproulx@efficios.com>
* Raffi Enficiaud, Max Planck Society
* Raumfeld <raumfeld.com>
* Roger Leigh <rleigh@codelibre.net>
* Rolf Eike Beer <eike@sf-mail.de>
* Roman Donchenko <roman.donchenko@itseez.com>
* Roman Kharitonov <roman.kharitonov@itseez.com>
* Ruslan Baratov
* Sebastian Holtermann <sebholt@xwmw.org>
* Stephen Kelly <steveire@gmail.com>
* Sylvain Joubert <joubert.sy@gmail.com>
* The Qt Company Ltd.
* Thomas Sondergaard <ts@medical-insight.com>
* Tobias Hunger <tobias.hunger@qt.io>
* Todd Gamblin <tgamblin@llnl.gov>
* Tristan Carel
* University of Dundee
* Vadim Zhukov
* Will Dicharry <wdicharry@stellarscience.com>

See version control history for details of individual contributions.

The above copyright and license notice applies to distributions of
CMake in source and binary form.  Third-party software packages supplied
with CMake under compatible licenses provide their own copyright notices
documented in corresponding subdirectories or source files.

------------------------------------------------------------------------------

CMake was initially developed by Kitware with the following sponsorship:

 * National Library of Medicine at the National Institutes of Health
   as part of the Insight Segmentation and Registration Toolkit (ITK).

 * US National Labs (Los Alamos, Livermore, Sandia) ASC Parallel
   Visualization Initiative.

 * National Alliance for Medical Image Computing (NAMIC) is funded by the
   National Institutes of Health through the NIH Roadmap for Medical Research,
   Grant U54 EB005149.

 * Kitware, Inc.


code:
<html>
<head>
<meta http-equiv="Refresh" content="0; url=https://cmake.org/" />
</head>
<body>
</body>
</html>


code:
'cppdap' is a C++11 library implementation of the Debug Adapter Protocol.
Version as of 2023-01-06
Copyright Google LLC

This product includes software developed at Google.


code:
KWSys - Kitware System Library
Copyright 2000-2016 Kitware, Inc. and Contributors
All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:

* Redistributions of source code must retain the above copyright
  notice, this list of conditions and the following disclaimer.

* Redistributions in binary form must reproduce the above copyright
  notice, this list of conditions and the following disclaimer in the
  documentation and/or other materials provided with the distribution.

* Neither the name of Kitware, Inc. nor the names of Contributors
  may be used to endorse or promote products derived from this
  software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

------------------------------------------------------------------------------

The following individuals and institutions are among the Contributors:

* Insight Software Consortium <insightsoftwareconsortium.org>

See version control history for details of individual contributions.


code:
'zlib' general purpose compression library
version 1.2.13, October 13th, 2022

Copyright (C) 1995-2022 Jean-loup Gailly and Mark Adler

This software is provided 'as-is', without any express or implied
warranty.  In no event will the authors be held liable for any damages
arising from the use of this software.

Permission is granted to anyone to use this software for any purpose,
including commercial applications, and to alter it and redistribute it
freely, subject to the following restrictions:

1. The origin of this software must not be misrepresented; you must not
   claim that you wrote the original software. If you use this software
   in a product, an acknowledgment in the product documentation would be
   appreciated but is not required.
2. Altered source versions must be plainly marked as such, and must not be
   misrepresented as being the original software.
3. This notice may not be removed or altered from any source distribution.

Jean-loup Gailly        Mark Adler
jloup@gzip.org          madler@alumni.caltech.edu


type: object

description: The presets specify the generator and the build directory, and optionally a list of variables and other arguments to pass to CMake.

description: A required integer representing the version of the JSON schema.

$ref: #/definitions/cmakeMinimumRequired

$ref: #/definitions/vendor

$ref: #/definitions/include

$ref: #/definitions/$schema

type: string

description: The schema against which to verify this document.

format: uri-reference

description: An optional object representing the minimum version of CMake needed to build this project.

type: integer

description: An optional integer representing the major version.

description: An optional integer representing the minor version.

description: An optional integer representing the patch version.

description: An optional map containing vendor-specific information. CMake does not interpret the contents of this field except to verify that it is a map if it does exist. However, the keys should be a vendor-specific domain name followed by a /-separated path. For example, the Example IDE 1.0 could use example.com/ExampleIDE/1.0. The value of each field can be anything desired by the vendor, though will typically be a map.

type: array

description: A configure preset object.

description: A configure preset object.

description: An optional object specifying trace options.

description: An optional string that specifies the trace mode.

enum: on off expand

description: An optional string that specifies the trace output format.

description: An optional string representing the path to one source file to be traced.

description: An optional array of strings representing the paths to source files to be traced.

description: A string representing the path to one source file to be traced.

description: An optional string specifying a path to a trace output file.

description: A configure preset object.

description: A configure preset object.

description: An optional string representing the path to the output binary directory. This field supports macro expansion. If a relative path is specified, it is calculated relative to the source directory. If binaryDir is not specified, the path is calculated using regular methods.

description: An optional string representing the generator to use for the preset. If generator is not specified, the normal generator discovery procedure is used. Note that for Visual Studio generators, unlike in the command line -G argument, you cannot include the platform name in the generator name. Use the architecture field instead.

description: An optional string representing the path to the toolchain file. This field supports macro expansion. If a relative path is specified, it is calculated relative to the build directory, and if not found, relative to the source directory.

description: An optional string representing the path to the installation directory. This field supports macro expansion. If a relative path is specified, it is calculated relative to the source directory.

$ref: #/definitions/topCondition

description: An optional array of configure preset objects.

description: A configure preset object.

description: A required string representing the machine-friendly name of the preset. This identifier is used in the --preset argument. There must not be two presets in the union of CMakePresets.json and CMakeUserPresets.json in the same directory with the same name.

type: boolean

description: An optional boolean specifying whether or not a preset should be hidden. If a preset is hidden, it cannot be used in the --preset= argument, will not show up in the CMake GUI, and does not have to have a valid generator or binaryDir, even from inheritance. Hidden presets are intended to be used as a base for other presets to inherit via the inherits field.

description: An optional string representing the name of the preset to inherit from.

description: An optional array of strings representing the names of presets to inherit from. The preset will inherit all of the fields from the inherits presets by default (except name, hidden, inherits, description, and displayName), but can override them as desired. If multiple inherits presets provide conflicting values for the same field, the earlier preset in the inherits list will be preferred. Presets in CMakePresets.json must not inherit from presets in CMakeUserPresets.json.

description: An optional map containing vendor-specific information. CMake does not interpret the contents of this field except to verify that it is a map if it does exist. However, it should follow the same conventions as the root-level vendor field. If vendors use their own per-preset vendor field, they should implement inheritance in a sensible manner when appropriate.

description: An optional string with a human-friendly name of the preset.

description: An optional string with a human-friendly description of the preset.

description: An optional string representing the generator to use for the preset. If generator is not specified, it must be inherited from the inherits preset (unless this preset is hidden). Note that for Visual Studio generators, unlike in the command line -G argument, you cannot include the platform name in the generator name. Use the architecture field instead.

description: An optional string representing the platform for generators that support it.

description: An optional object representing the platform for generators that support it.

description: An optional string representing the value.

description: An optional string telling CMake how to handle the field. Valid values are: "set" Set the respective value. This will result in an error for generators that do not support the respective field. "external" Do not set the value, even if the generator supports it. This is useful if, for example, a preset uses the Ninja generator, and an IDE knows how to set up the Visual C++ environment from the architecture and toolset fields. In that case, CMake will ignore the field, but the IDE can use them to set up the environment before invoking CMake.

enum: set external

description: An optional string representing the toolset for generators that support it.

description: An optional object representing the toolset for generators that support it.

description: An optional string representing the path to the output binary directory. This field supports macro expansion. If a relative path is specified, it is calculated relative to the source directory. If binaryDir is not specified, it must be inherited from the inherits preset (unless this preset is hidden).

description: An optional string representing the path to the CMake executable to use for this preset. This is reserved for use by IDEs, and is not used by CMake itself. IDEs that use this field should expand any macros in it.

description: An optional map of cache variables. The key is the variable name (which must not be an empty string). Cache variables are inherited through the inherits field, and the preset's variables will be the union of its own cacheVariables and the cacheVariables from all its parents. If multiple presets in this union define the same variable, the standard rules of inherits are applied.

description: Setting a variable to null causes it to not be set, even if a value was inherited from another preset.

description: A boolean representing the value of the variable. Equivalent to "TRUE" or "FALSE".

description: A string representing the value of the variable (which supports macro expansion).

description: An object representing the type and value of the variable.

description: An optional string representing the type of the variable. It should be BOOL, FILEPATH, PATH, STRING, or INTERNAL.

description: A required boolean representing the value of the variable. Equivalent to "TRUE" or "FALSE".

description: A required string representing the value of the variable. This field supports macro expansion.

description: An optional map of environment variables. The key is the variable name (which must not be an empty string). Each variable is set regardless of whether or not a value was given to it by the process's environment. This field supports macro expansion, and environment variables in this map may reference each other, and may be listed in any order, as long as such references do not cause a cycle (for example,if ENV_1 is $env{ENV_2}, ENV_2 may not be $env{ENV_1}.) Environment variables are inherited through the inherits field, and the preset's environment will be the union of its own environment and the environment from all its parents. If multiple presets in this union define the same variable, the standard rules of inherits are applied. Setting a variable to null causes it to not be set, even if a value was inherited from another preset.

description: A string representing the value of the variable.

description: An optional object specifying warnings.

description: An optional boolean. Equivalent to passing -Wdev or -Wno-dev on the command line. This may not be set to false if errors.dev is set to true.

description: An optional boolean. Equivalent to passing -Wdeprecated or -Wno-deprecated on the command line. This may not be set to false if errors.deprecated is set to true.

description: An optional boolean. Setting this to true is equivalent to passing --warn-uninitialized on the command line.

description: An optional boolean. Setting this to false is equivalent to passing --no-warn-unused-cli on the command line.

description: An optional boolean. Setting this to true is equivalent to passing --check-system-vars on the command line.

description: An optional object specifying errors.

description: An optional boolean. Equivalent to passing -Werror=dev or -Wno-error=dev on the command line. This may not be set to true if warnings.dev is set to false.

description: An optional boolean. Equivalent to passing -Werror=deprecated or -Wno-error=deprecated on the command line. This may not be set to true if warnings.deprecated is set to false.

description: An optional object specifying debug options.

description: An optional boolean. Setting this to true is equivalent to passing --debug-output on the command line.

description: An optional boolean. Setting this to true is equivalent to passing --debug-trycompile on the command line.

description: An optional boolean. Setting this to true is equivalent to passing --debug-find on the command line.

description: An optional array of build preset objects. Used to specify arguments to cmake --build. Available in version 4 and higher.

description: An optional string specifying the package resolve behavior. Valid values are "on" (packages are resolved prior to the build), "off" (packages are not resolved prior to the build), and "only" (packages are resolved, but no build will be performed).

enum: on off only

description: An optional array of build preset objects. Used to specify arguments to cmake --build. Available in version 3 and higher.

description: An optional array of build preset objects. Used to specify arguments to cmake --build. Available in version 2 and higher.

description: A required string representing the machine-friendly name of the preset. This identifier is used in the --preset argument. There must not be two presets (configure, build, test, package, or workflow) in the union of CMakePresets.json and CMakeUserPresets.json in the same directory with the same name.

description: An optional boolean specifying whether or not a preset should be hidden. If a preset is hidden, it cannot be used in the --preset argument and does not have to have a valid configurePreset, even from inheritance. Hidden presets are intended to be used as a base for other presets to inherit via the inherits field.

description: An optional string representing the name of the build preset to inherit from.

description: An optional array of strings representing the names of build presets to inherit from. The preset will inherit all of the fields from the inherits presets by default (except name, hidden, inherits, description, and displayName), but can override them as desired. If multiple inherits presets provide conflicting values for the same field, the earlier preset in the inherits list will be preferred. Presets in CMakePresets.json must not inherit from presets in CMakeUserPresets.json.

description: An optional string specifying the name of a configure preset to associate with this build preset. If configurePreset is not specified, it must be inherited from the inherits preset (unless this preset is hidden). The build tree directory is inferred from the configure preset.

description: An optional boolean that defaults to true. If true, the environment variables from the associated configure preset are inherited after all inherited build preset environments, but before environment variables explicitly specified in this build preset.

description: An optional integer. Equivalent to passing --parallel or -j on the command line.

description: An optional string. Equivalent to passing --target or -t on the command line. Vendors may ignore the targets property or hide build presets that explicitly specify targets.

description: An optional array of strings. Equivalent to passing --target or -t on the command line. Vendors may ignore the targets property or hide build presets that explicitly specify targets.

description: An optional string. Equivalent to passing --config on the command line.

description: An optional boolean. If true, equivalent to passing --clean-first on the command line.

description: An optional boolean. If true, equivalent to passing --verbose on the command line.

description: An optional array of strings. Equivalent to passing options after -- on the command line.

description: An optional string representing an option to pass after -- on the command line.

description: An optional array of test preset objects. Used to specify arguments to ctest. Available in version 6 and higher.

description: An optional object specifying output options.

description: An optional string specifying a path to a JUnit file. Equivalent to passing --output-junit on the command line.

description: An optional array of test preset objects. Used to specify arguments to ctest. Available in version 5 and higher.

description: An optional object specifying output options.

description: An optional string specifying the test output truncation mode. Equivalent to passing --test-output-truncation on the command line. Must be one of the following values: "tail", "middle", or "head".

description: An optional array of test preset objects. Used to specify arguments to ctest. Available in version 3 and higher.

description: An optional array of test preset objects. Used to specify arguments to ctest. Available in version 2 and higher.

description: An optional string representing the name of the test preset to inherit from.

description: An optional array of strings representing the names of test presets to inherit from. The preset will inherit all of the fields from the inherits presets by default (except name, hidden, inherits, description, and displayName), but can override them as desired. If multiple inherits presets provide conflicting values for the same field, the earlier preset in the inherits list will be preferred. Presets in CMakePresets.json must not inherit from presets in CMakeUserPresets.json.

description: An optional string representing the name of the preset to inherit from.

description: An optional string specifying the name of a configure preset to associate with this test preset. If configurePreset is not specified, it must be inherited from the inherits preset (unless this preset is hidden). The build tree directory is inferred from the configure preset.

description: An optional string with a human-friendly name of the preset.

description: An optional string with a human-friendly description of the preset.

description: An optional boolean that defaults to true. If true, the environment variables from the associated configure preset are inherited after all inherited test preset environments, but before environment variables explicitly specified in this test preset.

description: Setting a variable to null causes it to not be set, even if a value was inherited from another preset.

description: A string representing the value of the variable.

description: An optional string. Equivalent to passing --build-config on the command line.

description: An optional array of configuration options to overwrite options specified in the CTest configuration file. Equivalent to passing ``--overwrite`` for each value in the array.

description: An option written as a key-value pair in the form "key=value".

description: An optional object specifying output options.

description: An optional boolean. If true, equivalent to passing --progress on the command line.

description: An optional string specifying verbosity level. Valid values are "default" (equivalent to passing no verbosity flags on the command line), "verbose" (equivalent to passing --verbose on the command line), and "extra" (equivalent to passing --extra-verbose on the command line).

description: An optional boolean. If true, equivalent to passing --debug on the command line.

description: An optional boolean. If true, equivalent to passing --output-on-failure on the command line.

description: An optional boolean. If true, equivalent to passing --quiet on the command line.

description: An optional string specifying a path to a log file. Equivalent to passing --output-log on the command line.

description: An optional boolean. If false, equivalent to passing --no-label-summary on the command line.

description: An optional boolean. If false, equivalent to passing --no-subproject-summary on the command line.

description: An optional integer specifying the maximum output for passed tests in bytes. Equivalent to passing --test-output-size-passed on the command line.

description: An optional integer specifying the maximum output for failed tests in bytes. Equivalent to passing --test-output-size-failed on the command line.

description: An optional integer specifying the maximum width of a test name to output. Equivalent to passing --max-width on the command line.

description: An optional object specifying how to filter the tests to run.

description: An optional object specifying which tests to include.

description: An optional string specifying a regex for test names. Equivalent to passing --tests-regex on the command line.

description: An optional string specifying a regex for test labels. Equivalent to passing --label-regex on the command line.

description: An optional object specifying tests to include by test index.

description: An optional integer specifying a test index to start testing at.

description: An optional integer specifying a test index to stop testing at.

description: An optional integer specifying the increment.

description: An optional array of integers specifying specific test indices to run.

description: An integer specifying the test to run by index.

description: An optional string specifying a file with the command line syntax for --tests-information.

description: An optional boolean. Equivalent to passing --union on the command line.

description: An optional object specifying which tests to exclude.

description: An optional string specifying a regex for test names. Equivalent to passing --exclude-regex on the command line.

description: An optional string specifying a regex for test labels. Equivalent to passing --label-exclude on the command line.

description: An optional object specifying which fixtures to exclude from adding tests.

description: An optional string specifying a regex for text fixtures to exclude from adding any tests. Equivalent to --fixture-exclude-any on the command line.

description: An optional string specifying a regex for text fixtures to exclude from adding setup tests. Equivalent to --fixture-exclude-setup on the command line.

description: An optional string specifying a regex for text fixtures to exclude from adding cleanup tests. Equivalent to --fixture-exclude-cleanup on the command line.

description: An optional object specifying options for test execution.

description: An optional boolean. If true, equivalent to passing --stop-on-failure on the command line.

description: An optional boolean. If true, equivalent to passing -F on the command line.

description: An optional integer. Equivalent to passing --parallel on the command line.

description: An optional string. Equivalent to passing --resource-spec-file on the command line.

description: An optional integer. Equivalent to passing --test-load on the command line.

description: An optional string. Equivalent to passing --show-only on the command line. Value must be "human" or "json-v1".

description: An optional object specifying how to repeat tests. Equivalent to passing --repeat on the command line.

description: A required string. Must be one of the following values: "until-fail", "until-pass", or "after-timeout".

description: A required integer.

description: An optional boolean. If true, equivalent to passing --interactive-debug-mode 1 on the command line. If false, equivalent to passing --interactive-debug-mode 0 on the command line.

description: An optional boolean. If true, equivalent to passing --schedule-random on the command line.

description: An optional integer. Equivalent to passing --timeout on the command line.

description: An optional string specifying the behavior if no tests are found. Must be one of the following values: "default" (equivalent to not passing any value on the command line), "error" (equivalent to passing --no-tests=error on the command line), or "ignore" (equivalent to passing --no-tests-ignore on the command line).

description: An optional array of package preset objects. Used to specify arguments to cpack. Available in version 6 and higher.

description: An optional string representing the name of the package preset to inherit from.

description: An optional array of strings representing the names of package presets to inherit from. The preset will inherit all of the fields from the inherits presets by default (except name, hidden, inherits, description, and displayName), but can override them as desired. If multiple inherits presets provide conflicting values for the same field, the earlier preset in the inherits list will be preferred. Presets in CMakePresets.json must not inherit from presets in CMakeUserPresets.json.

description: An optional string representing the name of the preset to inherit from.

description: An optional string specifying the name of a configure preset to associate with this package preset. If configurePreset is not specified, it must be inherited from the inherits preset (unless this preset is hidden). The build tree directory is inferred from the configure preset.

description: An optional string with a human-friendly name of the preset.

description: An optional string with a human-friendly description of the preset.

description: An optional boolean that defaults to true. If true, the environment variables from the associated configure preset are inherited after all inherited package preset environments, but before environment variables explicitly specified in this package preset.

description: Setting a variable to null causes it to not be set, even if a value was inherited from another preset.

description: A string representing the value of the variable.

description: An optional list of strings representing generators for CPack to use.

description: An optional string representing the name of the CPack generator to use.

description: An optional list of strings representing build configurations for CPack to package.

description: An optional string representing the name of the configuration to use.

description: An optional map of variables to pass to CPack, equivalent to -D arguments. Each key is the name of a variable, and the value is the string to assign to that variable.

description: An optional string representing the value of the variable.

description: An optional string representing the config file for CPack to use.

description: An optional object specifying output options.

description: An optional boolean specifying whether or not to print debug information. A value of true is equivalent to passing --debug on the command line.

description: An optional boolean specifying whether or not to print verbosely. A value of true is equivalent to passing --verbose on the command line.

description: An optional string representing the package name.

description: An optional string representing the package version.

description: An optional string representing the directory in which to place the package.

description: An optional string representing the vendor name.

description: An optional array of workflow preset objects. Used to execute configure, build, test, and package presets in order. Available in version 6 and higher.

description: A required array of objects describing the steps of the workflow. The first step must be a configure preset, and all subsequent steps must be non-configure presets whose configurePreset field matches the starting configure preset.

description: A required string. The first step must be configure. Subsequent steps must be either build, test, or package.

description: A required string representing the name of the configure, build, test, or package preset to run as this workflow step.

description: A boolean which provides a constant value for the condition's evaluation.

description: A required string specifying the type of the condition.

description: A required boolean which provides a constant value for the condition's evaluation.

description: First string to compare. This field supports macro expansion.

description: Second string to compare. This field supports macro expansion.

description: A required string to search for. This field supports macro expansion.

description: A required list of strings to search. This field supports macro expansion, and uses short-circuit evaluation.

description: A required string to search. This field supports macro expansion.

description: A required regular expression to search for. This field supports macro expansion.

description: A required array of condition objects. These conditions use short-circuit evaluation.

description: Null indicates that the condition always evaluates to true and is not inherited.

description: An optional array of strings representing files to include. If the filenames are not absolute, they are considered relative to the current file.


code:
add_compile_definitions
-----------------------

.. versionadded:: 3.12

Add preprocessor definitions to the compilation of source files.

.. code-block:: cmake

  add_compile_definitions(<definition> ...)

Adds preprocessor definitions to the compiler command line.

The preprocessor definitions are added to the :prop_dir:`COMPILE_DEFINITIONS`
directory property for the current ``CMakeLists`` file. They are also added to
the :prop_tgt:`COMPILE_DEFINITIONS` target property for each target in the
current ``CMakeLists`` file.

Definitions are specified using the syntax ``VAR`` or ``VAR=value``.
Function-style definitions are not supported. CMake will automatically
escape the value correctly for the native build system (note that CMake
language syntax may require escapes to specify some values).

.. versionadded:: 3.26
  Any leading ``-D`` on an item will be removed.

.. |command_name| replace:: ``add_compile_definitions``
.. include:: GENEX_NOTE.txt

See Also
^^^^^^^^

* The command :command:`target_compile_definitions` adds target-specific definitions.


code:
add_compile_options
-------------------

Add options to the compilation of source files.

.. code-block:: cmake

  add_compile_options(<option> ...)

Adds options to the :prop_dir:`COMPILE_OPTIONS` directory property.
These options are used when compiling targets from the current
directory and below.

.. note::

  These options are not used when linking.
  See the :command:`add_link_options` command for that.

Arguments
^^^^^^^^^

.. |command_name| replace:: ``add_compile_options``
.. include:: GENEX_NOTE.txt

.. include:: OPTIONS_SHELL.txt

Example
^^^^^^^

Since different compilers support different options, a typical use of
this command is in a compiler-specific conditional clause:

.. code-block:: cmake

  if (MSVC)
      # warning level 4
      add_compile_options(/W4)
  else()
      # additional warnings
      add_compile_options(-Wall -Wextra -Wpedantic)
  endif()

To set per-language options, use the :genex:`$<COMPILE_LANGUAGE>`
or :genex:`$<COMPILE_LANGUAGE:languages>` generator expressions.

See Also
^^^^^^^^

* This command can be used to add any options. However, for
  adding preprocessor definitions and include directories it is recommended
  to use the more specific commands :command:`add_compile_definitions`
  and :command:`include_directories`.

* The command :command:`target_compile_options` adds target-specific options.

* This command adds compile options for all languages.
  Use the :genex:`COMPILE_LANGUAGE` generator expression to specify
  per-language compile options.

* The source file property :prop_sf:`COMPILE_OPTIONS` adds options to one
  source file.

* :command:`add_link_options` adds options for linking.

* :variable:`CMAKE_<LANG>_FLAGS` and :variable:`CMAKE_<LANG>_FLAGS_<CONFIG>`
  add language-wide flags passed to all invocations of the compiler.
  This includes invocations that drive compiling and those that drive linking.


code:
add_custom_command
------------------

Add a custom build rule to the generated build system.

There are two main signatures for ``add_custom_command``.

Generating Files
^^^^^^^^^^^^^^^^

The first signature is for adding a custom command to produce an output:

.. code-block:: cmake

  add_custom_command(OUTPUT output1 [output2 ...]
                     COMMAND command1 [ARGS] [args1...]
                     [COMMAND command2 [ARGS] [args2...] ...]
                     [MAIN_DEPENDENCY depend]
                     [DEPENDS [depends...]]
                     [BYPRODUCTS [files...]]
                     [IMPLICIT_DEPENDS <lang1> depend1
                                      [<lang2> depend2] ...]
                     [WORKING_DIRECTORY dir]
                     [COMMENT comment]
                     [DEPFILE depfile]
                     [JOB_POOL job_pool]
                     [JOB_SERVER_AWARE <bool>]
                     [VERBATIM] [APPEND] [USES_TERMINAL]
                     [COMMAND_EXPAND_LISTS]
                     [DEPENDS_EXPLICIT_ONLY])

This defines a command to generate specified ``OUTPUT`` file(s).
A target created in the same directory (``CMakeLists.txt`` file)
that specifies any output of the custom command as a source file
is given a rule to generate the file using the command at build time.

Do not list the output in more than one independent target that
may build in parallel or the instances of the rule may conflict.
Instead, use the :command:`add_custom_target` command to drive the
command and make the other targets depend on that one.  See the
`Example: Generating Files for Multiple Targets`_ below.

The options are:

``APPEND``
  Append the ``COMMAND`` and ``DEPENDS`` option values to the custom
  command for the first output specified.  There must have already
  been a previous call to this command with the same output.

  If the previous call specified the output via a generator expression,
  the output specified by the current call must match in at least one
  configuration after evaluating generator expressions.  In this case,
  the appended commands and dependencies apply to all configurations.

  The ``COMMENT``, ``MAIN_DEPENDENCY``, and ``WORKING_DIRECTORY``
  options are currently ignored when APPEND is given, but may be
  used in the future.

``BYPRODUCTS``
  .. versionadded:: 3.2

  Specify the files the command is expected to produce but whose
  modification time may or may not be newer than the dependencies.
  If a byproduct name is a relative path it will be interpreted
  relative to the build tree directory corresponding to the
  current source directory.
  Each byproduct file will be marked with the :prop_sf:`GENERATED`
  source file property automatically.

  *See policy* :policy:`CMP0058` *for the motivation behind this feature.*

  Explicit specification of byproducts is supported by the
  :generator:`Ninja` generator to tell the ``ninja`` build tool
  how to regenerate byproducts when they are missing.  It is
  also useful when other build rules (e.g. custom commands)
  depend on the byproducts.  Ninja requires a build rule for any
  generated file on which another rule depends even if there are
  order-only dependencies to ensure the byproducts will be
  available before their dependents build.

  The :ref:`Makefile Generators` will remove ``BYPRODUCTS`` and other
  :prop_sf:`GENERATED` files during ``make clean``.

  .. versionadded:: 3.20
    Arguments to ``BYPRODUCTS`` may use a restricted set of
    :manual:`generator expressions <cmake-generator-expressions(7)>`.
    :ref:`Target-dependent expressions <Target-Dependent Queries>` are not
    permitted.

  .. versionchanged:: 3.28
    In targets using :ref:`file sets`, custom command byproducts are now
    considered private unless they are listed in a non-private file set.
    See policy :policy:`CMP0154`.

``COMMAND``
  Specify the command-line(s) to execute at build time.
  If more than one ``COMMAND`` is specified they will be executed in order,
  but *not* necessarily composed into a stateful shell or batch script.
  (To run a full script, use the :command:`configure_file` command or the
  :command:`file(GENERATE)` command to create it, and then specify
  a ``COMMAND`` to launch it.)
  The optional ``ARGS`` argument is for backward compatibility and
  will be ignored.

  If ``COMMAND`` specifies an executable target name (created by the
  :command:`add_executable` command), it will automatically be replaced
  by the location of the executable created at build time if either of
  the following is true:

  * The target is not being cross-compiled (i.e. the
    :variable:`CMAKE_CROSSCOMPILING` variable is not set to true).
  * .. versionadded:: 3.6
      The target is being cross-compiled and an emulator is provided (i.e.
      its :prop_tgt:`CROSSCOMPILING_EMULATOR` target property is set).
      In this case, the contents of :prop_tgt:`CROSSCOMPILING_EMULATOR` will be
      prepended to the command before the location of the target executable.

  If neither of the above conditions are met, it is assumed that the
  command name is a program to be found on the ``PATH`` at build time.

  Arguments to ``COMMAND`` may use
  :manual:`generator expressions <cmake-generator-expressions(7)>`.
  Use the :genex:`TARGET_FILE` generator expression to refer to the location
  of a target later in the command line (i.e. as a command argument rather
  than as the command to execute).

  Whenever one of the following target based generator expressions are used as
  a command to execute or is mentioned in a command argument, a target-level
  dependency will be added automatically so that the mentioned target will be
  built before any target using this custom command
  (see policy :policy:`CMP0112`).

    * ``TARGET_FILE``
    * ``TARGET_LINKER_FILE``
    * ``TARGET_SONAME_FILE``
    * ``TARGET_PDB_FILE``

  This target-level dependency does NOT add a file-level dependency that would
  cause the custom command to re-run whenever the executable is recompiled.
  List target names with the ``DEPENDS`` option to add such file-level
  dependencies.

``COMMENT``
  Display the given message before the commands are executed at
  build time.

  .. versionadded:: 3.26
    Arguments to ``COMMENT`` may use
    :manual:`generator expressions <cmake-generator-expressions(7)>`.

``DEPENDS``
  Specify files on which the command depends.  Each argument is converted
  to a dependency as follows:

  1. If the argument is the name of a target (created by the
     :command:`add_custom_target`, :command:`add_executable`, or
     :command:`add_library` command) a target-level dependency is
     created to make sure the target is built before any target
     using this custom command.  Additionally, if the target is an
     executable or library, a file-level dependency is created to
     cause the custom command to re-run whenever the target is
     recompiled.

  2. If the argument is an absolute path, a file-level dependency
     is created on that path.

  3. If the argument is the name of a source file that has been
     added to a target or on which a source file property has been set,
     a file-level dependency is created on that source file.

  4. If the argument is a relative path and it exists in the current
     source directory, a file-level dependency is created on that
     file in the current source directory.

  5. Otherwise, a file-level dependency is created on that path relative
     to the current binary directory.

  If any dependency is an ``OUTPUT`` of another custom command in the same
  directory (``CMakeLists.txt`` file), CMake automatically brings the other
  custom command into the target in which this command is built.

  .. versionadded:: 3.16
    A target-level dependency is added if any dependency is listed as
    ``BYPRODUCTS`` of a target or any of its build events in the same
    directory to ensure the byproducts will be available.

  If ``DEPENDS`` is not specified, the command will run whenever
  the ``OUTPUT`` is missing; if the command does not actually
  create the ``OUTPUT``, the rule will always run.

  .. versionadded:: 3.1
    Arguments to ``DEPENDS`` may use
    :manual:`generator expressions <cmake-generator-expressions(7)>`.

``COMMAND_EXPAND_LISTS``
  .. versionadded:: 3.8

  Lists in ``COMMAND`` arguments will be expanded, including those
  created with
  :manual:`generator expressions <cmake-generator-expressions(7)>`,
  allowing ``COMMAND`` arguments such as
  ``${CC} "-I$<JOIN:$<TARGET_PROPERTY:foo,INCLUDE_DIRECTORIES>,;-I>" foo.cc``
  to be properly expanded.

``IMPLICIT_DEPENDS``
  Request scanning of implicit dependencies of an input file.
  The language given specifies the programming language whose
  corresponding dependency scanner should be used.
  Currently only ``C`` and ``CXX`` language scanners are supported.
  The language has to be specified for every file in the
  ``IMPLICIT_DEPENDS`` list.  Dependencies discovered from the
  scanning are added to those of the custom command at build time.
  Note that the ``IMPLICIT_DEPENDS`` option is currently supported
  only for Makefile generators and will be ignored by other generators.

  .. note::

    This option cannot be specified at the same time as ``DEPFILE`` option.

``JOB_POOL``
  .. versionadded:: 3.15

  Specify a :prop_gbl:`pool <JOB_POOLS>` for the :generator:`Ninja`
  generator. Incompatible with ``USES_TERMINAL``, which implies
  the ``console`` pool.
  Using a pool that is not defined by :prop_gbl:`JOB_POOLS` causes
  an error by ninja at build time.

``JOB_SERVER_AWARE``
  .. versionadded:: 3.28

  Specify that the command is GNU Make job server aware.

  For the :generator:`Unix Makefiles`, :generator:`MSYS Makefiles`, and
  :generator:`MinGW Makefiles` generators this will add the ``+`` prefix to the
  recipe line. See the `GNU Make Documentation`_ for more information.

  This option is silently ignored by other generators.

.. _`GNU Make Documentation`: https://www.gnu.org/software/make/manual/html_node/MAKE-Variable.html

``MAIN_DEPENDENCY``
  Specify the primary input source file to the command.  This is
  treated just like any value given to the ``DEPENDS`` option
  but also suggests to Visual Studio generators where to hang
  the custom command. Each source file may have at most one command
  specifying it as its main dependency. A compile command (i.e. for a
  library or an executable) counts as an implicit main dependency which
  gets silently overwritten by a custom command specification.

``OUTPUT``
  Specify the output files the command is expected to produce.
  Each output file will be marked with the :prop_sf:`GENERATED`
  source file property automatically.
  If the output of the custom command is not actually created
  as a file on disk it should be marked with the :prop_sf:`SYMBOLIC`
  source file property.

  If an output file name is a relative path, its absolute path is
  determined by interpreting it relative to:

  1. the build directory corresponding to the current source directory
     (:variable:`CMAKE_CURRENT_BINARY_DIR`), or

  2. the current source directory (:variable:`CMAKE_CURRENT_SOURCE_DIR`).

  The path in the build directory is preferred unless the path in the
  source tree is mentioned as an absolute source file path elsewhere
  in the current directory.

  .. versionadded:: 3.20
    Arguments to ``OUTPUT`` may use a restricted set of
    :manual:`generator expressions <cmake-generator-expressions(7)>`.
    :ref:`Target-dependent expressions <Target-Dependent Queries>` are not
    permitted.

  .. versionchanged:: 3.28
    In targets using :ref:`file sets`, custom command outputs are now
    considered private unless they are listed in a non-private file set.
    See policy :policy:`CMP0154`.

``USES_TERMINAL``
  .. versionadded:: 3.2

  The command will be given direct access to the terminal if possible.
  With the :generator:`Ninja` generator, this places the command in
  the ``console`` :prop_gbl:`pool <JOB_POOLS>`.

``VERBATIM``
  All arguments to the commands will be escaped properly for the
  build tool so that the invoked command receives each argument
  unchanged.  Note that one level of escapes is still used by the
  CMake language processor before add_custom_command even sees the
  arguments.  Use of ``VERBATIM`` is recommended as it enables
  correct behavior.  When ``VERBATIM`` is not given the behavior
  is platform specific because there is no protection of
  tool-specific special characters.

``WORKING_DIRECTORY``
  Execute the command with the given current working directory.
  If it is a relative path it will be interpreted relative to the
  build tree directory corresponding to the current source directory.

  .. versionadded:: 3.13
    Arguments to ``WORKING_DIRECTORY`` may use
    :manual:`generator expressions <cmake-generator-expressions(7)>`.

``DEPFILE``
  .. versionadded:: 3.7

  Specify a depfile which holds dependencies for the custom command. It is
  usually emitted by the custom command itself.  This keyword may only be used
  if the generator supports it, as detailed below.

  The expected format, compatible with what is generated by ``gcc`` with the
  option ``-M``, is independent of the generator or platform.

  The formal syntax, as specified using
  `BNF <https://en.wikipedia.org/wiki/Backus%E2%80%93Naur_form>`_ notation with
  the regular extensions, is the following:

  .. raw:: latex

    \begin{small}

  .. productionlist:: depfile
    depfile: `rule`*
    rule: `targets` (':' (`separator` `dependencies`?)?)? `eol`
    targets: `target` (`separator` `target`)* `separator`*
    target: `pathname`
    dependencies: `dependency` (`separator` `dependency`)* `separator`*
    dependency: `pathname`
    separator: (`space` | `line_continue`)+
    line_continue: '\' `eol`
    space: ' ' | '\t'
    pathname: `character`+
    character: `std_character` | `dollar` | `hash` | `whitespace`
    std_character: <any character except '$', '#' or ' '>
    dollar: '$$'
    hash: '\#'
    whitespace: '\ '
    eol: '\r'? '\n'

  .. raw:: latex

    \end{small}

  .. note::

    As part of ``pathname``, any slash and backslash is interpreted as
    a directory separator.

  .. versionadded:: 3.7
    The :generator:`Ninja` generator supports ``DEPFILE`` since the keyword
    was first added.

  .. versionadded:: 3.17
    Added the :generator:`Ninja Multi-Config` generator, which included
    support for the ``DEPFILE`` keyword.

  .. versionadded:: 3.20
    Added support for :ref:`Makefile Generators`.

    .. note::

      ``DEPFILE`` cannot be specified at the same time as the
      ``IMPLICIT_DEPENDS`` option for :ref:`Makefile Generators`.

  .. versionadded:: 3.21
    Added support for :ref:`Visual Studio Generators` with VS 2012 and above,
    and for the :generator:`Xcode` generator.  Support for
    :manual:`generator expressions <cmake-generator-expressions(7)>` was also
    added.

  .. versionadded:: 3.29
    The :ref:`Ninja Generators` will now incorporate the dependencies into its
    "deps log" database if the file is not listed in ``OUTPUTS`` or
    ``BYPRODUCTS``.

  Using ``DEPFILE`` with generators other than those listed above is an error.

  If the ``DEPFILE`` argument is relative, it should be relative to
  :variable:`CMAKE_CURRENT_BINARY_DIR`, and any relative paths inside the
  ``DEPFILE`` should also be relative to :variable:`CMAKE_CURRENT_BINARY_DIR`.
  See policy :policy:`CMP0116`, which is always ``NEW`` for
  :ref:`Makefile Generators`, :ref:`Visual Studio Generators`,
  and the :generator:`Xcode` generator.

``DEPENDS_EXPLICIT_ONLY``

  .. versionadded:: 3.27

  Indicates that the command's ``DEPENDS`` argument represents all files
  required by the command and implicit dependencies are not required.

  Without this option, if any target uses the output of the custom command,
  CMake will consider that target's dependencies as implicit dependencies for
  the custom command in case this custom command requires files implicitly
  created by those targets.

  This option can be enabled on all custom commands by setting
  :variable:`CMAKE_ADD_CUSTOM_COMMAND_DEPENDS_EXPLICIT_ONLY` to ``ON``.

  Only the :ref:`Ninja Generators` actually use this information to remove
  unnecessary implicit dependencies.

  See also the :prop_tgt:`OPTIMIZE_DEPENDENCIES` target property, which may
  provide another way for reducing the impact of target dependencies in some
  scenarios.

Examples: Generating Files
^^^^^^^^^^^^^^^^^^^^^^^^^^

Custom commands may be used to generate source files.
For example, the code:

.. code-block:: cmake

  add_custom_command(
    OUTPUT out.c
    COMMAND someTool -i ${CMAKE_CURRENT_SOURCE_DIR}/in.txt
                     -o out.c
    DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/in.txt
    VERBATIM)
  add_library(myLib out.c)

adds a custom command to run ``someTool`` to generate ``out.c`` and then
compile the generated source as part of a library.  The generation rule
will re-run whenever ``in.txt`` changes.

.. versionadded:: 3.20
  One may use generator expressions to specify per-configuration outputs.
  For example, the code:

  .. code-block:: cmake

    add_custom_command(
      OUTPUT "out-$<CONFIG>.c"
      COMMAND someTool -i ${CMAKE_CURRENT_SOURCE_DIR}/in.txt
                       -o "out-$<CONFIG>.c"
                       -c "$<CONFIG>"
      DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/in.txt
      VERBATIM)
    add_library(myLib "out-$<CONFIG>.c")

  adds a custom command to run ``someTool`` to generate ``out-<config>.c``,
  where ``<config>`` is the build configuration, and then compile the generated
  source as part of a library.

Example: Generating Files for Multiple Targets
""""""""""""""""""""""""""""""""""""""""""""""

If multiple independent targets need the same custom command output,
it must be attached to a single custom target on which they all depend.
Consider the following example:

.. code-block:: cmake

  add_custom_command(
    OUTPUT table.csv
    COMMAND makeTable -i ${CMAKE_CURRENT_SOURCE_DIR}/input.dat
                      -o table.csv
    DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/input.dat
    VERBATIM)
  add_custom_target(generate_table_csv DEPENDS table.csv)

  add_custom_command(
    OUTPUT foo.cxx
    COMMAND genFromTable -i table.csv -case foo -o foo.cxx
    DEPENDS table.csv           # file-level dependency
            generate_table_csv  # target-level dependency
    VERBATIM)
  add_library(foo foo.cxx)

  add_custom_command(
    OUTPUT bar.cxx
    COMMAND genFromTable -i table.csv -case bar -o bar.cxx
    DEPENDS table.csv           # file-level dependency
            generate_table_csv  # target-level dependency
    VERBATIM)
  add_library(bar bar.cxx)

Output ``foo.cxx`` is needed only by target ``foo`` and output ``bar.cxx``
is needed only by target ``bar``, but *both* targets need ``table.csv``,
transitively.  Since ``foo`` and ``bar`` are independent targets that may
build concurrently, we prevent them from racing to generate ``table.csv``
by placing its custom command in a separate target, ``generate_table_csv``.
The custom commands generating ``foo.cxx`` and ``bar.cxx`` each specify a
target-level dependency on ``generate_table_csv``, so the targets using them,
``foo`` and ``bar``, will not build until after target ``generate_table_csv``
is built.

.. _`add_custom_command(TARGET)`:

Build Events
^^^^^^^^^^^^

The second signature adds a custom command to a target such as a
library or executable.  This is useful for performing an operation
before or after building the target.  The command becomes part of the
target and will only execute when the target itself is built.  If the
target is already built, the command will not execute.

.. code-block:: cmake

  add_custom_command(TARGET <target>
                     PRE_BUILD | PRE_LINK | POST_BUILD
                     COMMAND command1 [ARGS] [args1...]
                     [COMMAND command2 [ARGS] [args2...] ...]
                     [BYPRODUCTS [files...]]
                     [WORKING_DIRECTORY dir]
                     [COMMENT comment]
                     [VERBATIM]
                     [COMMAND_EXPAND_LISTS])

This defines a new command that will be associated with building the
specified ``<target>``.  The ``<target>`` must be defined in the current
directory; targets defined in other directories may not be specified.

When the command will happen is determined by which
of the following is specified:

``PRE_BUILD``
  This option has unique behavior for the :ref:`Visual Studio Generators`.
  When using one of the Visual Studio generators, the command will run before
  any other rules are executed within the target.  With all other generators,
  this option behaves the same as ``PRE_LINK`` instead.  Because of this,
  it is recommended to avoid using ``PRE_BUILD`` except when it is known that
  a Visual Studio generator is being used.
``PRE_LINK``
  Run after sources have been compiled but before linking the binary
  or running the librarian or archiver tool of a static library.
  This is not defined for targets created by the
  :command:`add_custom_target` command.
``POST_BUILD``
  Run after all other rules within the target have been executed.

Projects should always specify one of the above three keywords when using
the ``TARGET`` form.  For backward compatibility reasons, ``POST_BUILD`` is
assumed if no such keyword is given, but projects should explicitly provide
one of the keywords to make clear the behavior they expect.

.. note::
  Because generator expressions can be used in custom commands,
  it is possible to define ``COMMAND`` lines or whole custom commands
  which evaluate to empty strings for certain configurations.
  For **Visual Studio 12 2013 (and newer)** generators these command
  lines or custom commands will be omitted for the specific
  configuration and no "empty-string-command" will be added.

  This allows adding individual build events for every configuration.

.. versionadded:: 3.21
  Support for target-dependent generator expressions.

.. versionadded:: 3.29
  The ``<target>`` may be an :ref:`ALIAS target <Alias Targets>`.

Examples: Build Events
^^^^^^^^^^^^^^^^^^^^^^

A ``POST_BUILD`` event may be used to post-process a binary after linking.
For example, the code:

.. code-block:: cmake

  add_executable(myExe myExe.c)
  add_custom_command(
    TARGET myExe POST_BUILD
    COMMAND someHasher -i "$<TARGET_FILE:myExe>"
                       -o "$<TARGET_FILE:myExe>.hash"
    VERBATIM)

will run ``someHasher`` to produce a ``.hash`` file next to the executable
after linking.

.. versionadded:: 3.20
  One may use generator expressions to specify per-configuration byproducts.
  For example, the code:

  .. code-block:: cmake

    add_library(myPlugin MODULE myPlugin.c)
    add_custom_command(
      TARGET myPlugin POST_BUILD
      COMMAND someHasher -i "$<TARGET_FILE:myPlugin>"
                         --as-code "myPlugin-hash-$<CONFIG>.c"
      BYPRODUCTS "myPlugin-hash-$<CONFIG>.c"
      VERBATIM)
    add_executable(myExe myExe.c "myPlugin-hash-$<CONFIG>.c")

  will run ``someHasher`` after linking ``myPlugin``, e.g. to produce a ``.c``
  file containing code to check the hash of ``myPlugin`` that the ``myExe``
  executable can use to verify it before loading.

Ninja Multi-Config
^^^^^^^^^^^^^^^^^^

.. versionadded:: 3.20

  ``add_custom_command`` supports the :generator:`Ninja Multi-Config`
  generator's cross-config capabilities. See the generator documentation
  for more information.

See Also
^^^^^^^^

* :command:`add_custom_target`


code:
add_custom_target
-----------------

Add a target with no output so it will always be built.

.. code-block:: cmake

  add_custom_target(Name [ALL] [command1 [args1...]]
                    [COMMAND command2 [args2...] ...]
                    [DEPENDS depend depend depend ... ]
                    [BYPRODUCTS [files...]]
                    [WORKING_DIRECTORY dir]
                    [COMMENT comment]
                    [JOB_POOL job_pool]
                    [JOB_SERVER_AWARE <bool>]
                    [VERBATIM] [USES_TERMINAL]
                    [COMMAND_EXPAND_LISTS]
                    [SOURCES src1 [src2...]])

Adds a target with the given name that executes the given commands.
The target has no output file and is *always considered out of date*
even if the commands try to create a file with the name of the target.
Use the :command:`add_custom_command` command to generate a file with
dependencies.  By default nothing depends on the custom target.  Use
the :command:`add_dependencies` command to add dependencies to or
from other targets.

The options are:

``ALL``
  Indicate that this target should be added to the default build
  target so that it will be run every time (the command cannot be
  called ``ALL``).

``BYPRODUCTS``
  .. versionadded:: 3.2

  Specify the files the command is expected to produce but whose
  modification time may or may not be updated on subsequent builds.
  If a byproduct name is a relative path it will be interpreted
  relative to the build tree directory corresponding to the
  current source directory.
  Each byproduct file will be marked with the :prop_sf:`GENERATED`
  source file property automatically.

  *See policy* :policy:`CMP0058` *for the motivation behind this feature.*

  Explicit specification of byproducts is supported by the
  :generator:`Ninja` generator to tell the ``ninja`` build tool
  how to regenerate byproducts when they are missing.  It is
  also useful when other build rules (e.g. custom commands)
  depend on the byproducts.  Ninja requires a build rule for any
  generated file on which another rule depends even if there are
  order-only dependencies to ensure the byproducts will be
  available before their dependents build.

  The :ref:`Makefile Generators` will remove ``BYPRODUCTS`` and other
  :prop_sf:`GENERATED` files during ``make clean``.

  .. versionadded:: 3.20
    Arguments to ``BYPRODUCTS`` may use a restricted set of
    :manual:`generator expressions <cmake-generator-expressions(7)>`.
    :ref:`Target-dependent expressions <Target-Dependent Queries>` are not
    permitted.

  .. versionchanged:: 3.28
    In custom targets using :ref:`file sets`, byproducts are now
    considered private unless they are listed in a non-private file set.
    See policy :policy:`CMP0154`.

``COMMAND``
  Specify the command-line(s) to execute at build time.
  If more than one ``COMMAND`` is specified they will be executed in order,
  but *not* necessarily composed into a stateful shell or batch script.
  (To run a full script, use the :command:`configure_file` command or the
  :command:`file(GENERATE)` command to create it, and then specify
  a ``COMMAND`` to launch it.)

  If ``COMMAND`` specifies an executable target name (created by the
  :command:`add_executable` command), it will automatically be replaced
  by the location of the executable created at build time if either of
  the following is true:

  * The target is not being cross-compiled (i.e. the
    :variable:`CMAKE_CROSSCOMPILING` variable is not set to true).
  * .. versionadded:: 3.6
      The target is being cross-compiled and an emulator is provided (i.e.
      its :prop_tgt:`CROSSCOMPILING_EMULATOR` target property is set).
      In this case, the contents of :prop_tgt:`CROSSCOMPILING_EMULATOR` will be
      prepended to the command before the location of the target executable.

  If neither of the above conditions are met, it is assumed that the
  command name is a program to be found on the ``PATH`` at build time.

  Arguments to ``COMMAND`` may use
  :manual:`generator expressions <cmake-generator-expressions(7)>`.
  Use the :genex:`TARGET_FILE` generator expression to refer to the location
  of a target later in the command line (i.e. as a command argument rather
  than as the command to execute).

  Whenever one of the following target based generator expressions are used as
  a command to execute or is mentioned in a command argument, a target-level
  dependency will be added automatically so that the mentioned target will be
  built before this custom target (see policy :policy:`CMP0112`).

    * ``TARGET_FILE``
    * ``TARGET_LINKER_FILE``
    * ``TARGET_SONAME_FILE``
    * ``TARGET_PDB_FILE``

  The command and arguments are optional and if not specified an empty
  target will be created.

``COMMENT``
  Display the given message before the commands are executed at
  build time.

  .. versionadded:: 3.26
    Arguments to ``COMMENT`` may use
    :manual:`generator expressions <cmake-generator-expressions(7)>`.

``DEPENDS``
  Reference files and outputs of custom commands created with
  :command:`add_custom_command` command calls in the same directory
  (``CMakeLists.txt`` file).  They will be brought up to date when
  the target is built.

  .. versionchanged:: 3.16
    A target-level dependency is added if any dependency is a byproduct
    of a target or any of its build events in the same directory to ensure
    the byproducts will be available before this target is built.

  Use the :command:`add_dependencies` command to add dependencies
  on other targets.

``COMMAND_EXPAND_LISTS``
  .. versionadded:: 3.8

  Lists in ``COMMAND`` arguments will be expanded, including those
  created with
  :manual:`generator expressions <cmake-generator-expressions(7)>`,
  allowing ``COMMAND`` arguments such as
  ``${CC} "-I$<JOIN:$<TARGET_PROPERTY:foo,INCLUDE_DIRECTORIES>,;-I>" foo.cc``
  to be properly expanded.

``JOB_POOL``
  .. versionadded:: 3.15

  Specify a :prop_gbl:`pool <JOB_POOLS>` for the :generator:`Ninja`
  generator. Incompatible with ``USES_TERMINAL``, which implies
  the ``console`` pool.
  Using a pool that is not defined by :prop_gbl:`JOB_POOLS` causes
  an error by ninja at build time.

``JOB_SERVER_AWARE``
  .. versionadded:: 3.28

  Specify that the command is GNU Make job server aware.

  For the :generator:`Unix Makefiles`, :generator:`MSYS Makefiles`, and
  :generator:`MinGW Makefiles` generators this will add the ``+`` prefix to the
  recipe line. See the `GNU Make Documentation`_ for more information.

  This option is silently ignored by other generators.

.. _`GNU Make Documentation`: https://www.gnu.org/software/make/manual/html_node/MAKE-Variable.html

``SOURCES``
  Specify additional source files to be included in the custom target.
  Specified source files will be added to IDE project files for
  convenience in editing even if they have no build rules.

``VERBATIM``
  All arguments to the commands will be escaped properly for the
  build tool so that the invoked command receives each argument
  unchanged.  Note that one level of escapes is still used by the
  CMake language processor before ``add_custom_target`` even sees
  the arguments.  Use of ``VERBATIM`` is recommended as it enables
  correct behavior.  When ``VERBATIM`` is not given the behavior
  is platform specific because there is no protection of
  tool-specific special characters.

``USES_TERMINAL``
  .. versionadded:: 3.2

  The command will be given direct access to the terminal if possible.
  With the :generator:`Ninja` generator, this places the command in
  the ``console`` :prop_gbl:`pool <JOB_POOLS>`.

``WORKING_DIRECTORY``
  Execute the command with the given current working directory.
  If it is a relative path it will be interpreted relative to the
  build tree directory corresponding to the current source directory.

  .. versionadded:: 3.13
    Arguments to ``WORKING_DIRECTORY`` may use
    :manual:`generator expressions <cmake-generator-expressions(7)>`.

Ninja Multi-Config
^^^^^^^^^^^^^^^^^^

.. versionadded:: 3.20

  ``add_custom_target`` supports the :generator:`Ninja Multi-Config`
  generator's cross-config capabilities. See the generator documentation
  for more information.

See Also
^^^^^^^^

* :command:`add_custom_command`


code:
add_definitions
---------------

Add ``-D`` define flags to the compilation of source files.

.. code-block:: cmake

  add_definitions(-DFOO -DBAR ...)

Adds definitions to the compiler command line for targets in the current
directory, whether added before or after this command is invoked, and for
the ones in sub-directories added after. This command can be used to add any
flags, but it is intended to add preprocessor definitions.

.. note::

  This command has been superseded by alternatives:

  * Use :command:`add_compile_definitions` to add preprocessor definitions.
  * Use :command:`include_directories` to add include directories.
  * Use :command:`add_compile_options` to add other options.

Flags beginning in ``-D`` or ``/D`` that look like preprocessor definitions are
automatically added to the :prop_dir:`COMPILE_DEFINITIONS` directory
property for the current directory.  Definitions with non-trivial values
may be left in the set of flags instead of being converted for reasons of
backwards compatibility.  See documentation of the
:prop_dir:`directory <COMPILE_DEFINITIONS>`,
:prop_tgt:`target <COMPILE_DEFINITIONS>`,
:prop_sf:`source file <COMPILE_DEFINITIONS>` ``COMPILE_DEFINITIONS``
properties for details on adding preprocessor definitions to specific
scopes and configurations.

See Also
^^^^^^^^

* The :manual:`cmake-buildsystem(7)` manual for more on defining
  buildsystem properties.


code:
add_dependencies
----------------

Add a dependency between top-level targets.

.. code-block:: cmake

  add_dependencies(<target> [<target-dependency>]...)

Makes a top-level ``<target>`` depend on other top-level targets to
ensure that they build before ``<target>`` does.  A top-level target
is one created by one of the :command:`add_executable`,
:command:`add_library`, or :command:`add_custom_target` commands
(but not targets generated by CMake like ``install``).

Dependencies added to an :ref:`imported target <Imported Targets>`
or an :ref:`interface library <Interface Libraries>` are followed
transitively in its place since the target itself does not build.

.. versionadded:: 3.3
  Allow adding dependencies to interface libraries.

See Also
^^^^^^^^

* The ``DEPENDS`` option of :command:`add_custom_target` and
  :command:`add_custom_command` commands for adding file-level
  dependencies in custom rules.

* The :prop_sf:`OBJECT_DEPENDS` source file property to add
  file-level dependencies to object files.