Общие сведения

Содержит библиотечный код, расширяющий и упрощающий различные операции в программах на языке C. То есть содержит программные инструменты, которые можно использовать в любой развитой программе на языке C. Весь код по возможности совместим со стандартамим C99, C++98 и C++2011, поэтому легко может также использоваться в C++ программах (с соответствующими оптимизациями). Очень важно не уходить далеко от C99. По состоянию на 2015-ый год C11 не везде хорошо поддерживается. Кроме этого, есть интересные стандарты типа OpenCL, совместимые с C99. Библиотека может использоваться при разработке под различные операционные системы и без таковых, с любой архитектурой и разрядностью процессора. Основная цель существования библиотеки - организация удобного слоя между операционными системами (которые, как правило, имеют C-интерфейс), компиляторами, поддерживающими различные расширения и прикладными программами на C/C++.

Макросы и определения экспортируемые библиотекой имеют префикс CT. Внутренние определения (a также типы, функции) имеют постфикс __ (например CT_B8__). Все переменные, константы и функции для C++ программ располагаются в пространстве имён ctools.

Состав

• Определение компиляторов, системных библиотек, операционных систем и унификация их расширений;
• Поддержка runtime и compiletime assert;
• Двоичные константы и битовые операции;
• Настраиваемые compiletime и runtime трассировочные сообщения;
• Препроцессорные вычисления;
• Работа с указателями;
• Перечисления (enums) с расширенными возможностями;
• Различные константы.

Подкаталоги интерфейса (include/ctools):

• mcu - содержит примитивы для работы с микроконтроллерами. Со временем, возможно, будут вынесены в отдельную библиотеку;
• net - содержит примитивы для работы с сетями. Со временем, возможно, будут вынесены в отдельную библиотеку;
• os - не предназначено для использования в проектах с целевой платформой "голое железо";
• predef - см. секцию "Обоснование решений";
• std - замена стандартным файлам с целью обойти ограничения платформ, компиляторов и привнести удобные расширения на неподдерживающие их конфигурации. Некоторые модули содержат "wrapper'ы" над библиотечными функциями, единственный смысл существования которых - добавить логирование операций.

Другие известные проекты по этой тематике

• boost/predef
• predef
• Qt/qtbase
• P99
• libowfat

Все эти проекты могут служить источником каких-то идей, но скорее всего они будут лицензионно несовместимы. Библиотека предполагается минималистичной и поэтому не тянет много зависимостей. Идеи для predef можно подчерпнуть в boost/predef, predef и Qt/qtbase . Все эти проекты можно было бы сделать подпроектами, но:

• Эти подпроекты нужно будет пустить в интерфейс ctools. Если внешняя программа будет использовать, например, свой boost/predef, то для неё будет доступны 2 версии boost/predef, с возможным конфликтом;
• predef с sourceforge.net в коде не развивается с 2005-го года, но wiki актуальна;
• Qt/qtbase - это C++ библиотека, не наш случай.

Целевые конфигурации

Любые, на которых работают компиляторы C99, C++98 и выше, с любой разрядностью процессора и любым порядком байт В качестве исключения допускаются некоторые не совсем совместимые C99 компиляторы типа MS VC++. Хотя тестирования преимущественно происходит на платформах:

• Linux x86_64 + gcc;
• Linux x86_64 + icc;
• Linux x86_64 + clang;
• Windows XP + minwg;
• Windows XP + MSVC2010.

Библиотека должна работать как на ограниченных в ресурсах платформах (микроконтроллерах без ОС) так и под управлением современных ОС. Из-за того, что все возможности библиотеки на конкретной платформе могут быть не доступны (например, реализации мьютексов или функции msleep() на базе системных вызовов) библиотека не должна терять работоспособность. Предполагается, что можно использовать любые определения из интерфейса библиотеки в любых комбинациях. Для этого они максимально распределяются по отдельным модулям, чтобы уменьшить взаимные зависимости. Проект никогда не тестировался на совместимость с gcc версии меньше чем 4.2.4. Проверена компилиция с gLibc 2.19. Совместимость на ограниченных платформах должна отслеживаться разработчиком.

Зависимости

Все скрипты проекта написаны на языке Python (Рекомендуется Python 3.3 и выше). Проект можно собирать с использованием системы сборки CMake. В этом случае потребуется CMake 2.8.3 и выше. Обе эти зависимости не являются обязательными. В проекте используются системы сборки Git и Mercurial. На некоторых системах может потребоваться установка системной библиотеки libiberty.

В системе также должны быть установлены все зависимости pyrepo, cmake_tools и зависимости из каталога tests.

Сборка

Существует 4 варианта использования:

• Сборка не осуществляется. Сборкой должен заниматься тот проект, который использует эту библиотеку. Для этого он должен указать пути для поиска заголовочных файлов include и build_info/include. Линковать все модули из src и подкаталогов src (если таковые нужны). Может потребоваться определение препроцессорных идентификаторов для выбора режима работы различных подсистем. По мере развития библиотеки этот вариант сборки нужно сопровождать. Вся актуальная информация может браться из файлов CMakeLists.txt проектов libctools и libcpptools. Этот вариант сборки можно рекомендовать только в тех случаях, когда следующие варианты не удаётся осуществить по каким-то причинам;

• Сборка осуществляется с использованием CMakeLists.txt . При этом формируется иерархия проектов с описанием сборки. Вышестоящий проект должен включать libctools посредством директивы:

  add_subdirectory(libctools)

  Может потребоваться указание других переменных CMake и переменных окружения. Пример реализации такой сборки можно посмотреть в корне libcpptools;

• Сборка осуществляется с использованием единственного CMakeLists.txt . Большинство возможностей библиотеки выключено при сборке. Этот вариант может быть удобен для работы с исходниками библиотеки в различных IDE;

• Сборка осуществляется с использованием скриптов cmake_*.py . Собранная библиотека в релизной или отладочной конфигурации помещается в определённый подкаталог build.

Ниже перечислены некоторые идентификаторы, которые могут быть заданы при сборке под микроконтроллерные платформы:

• CT_NO_DYNAMIC_MEMORY - библиотека будет лишена поддержки динамической памяти и некоторых возможностей неотрывно зависящих от неё;
• CT_RETARGET_PUTCHAR - включить код стандартной функции putchar(), чтобы исправить ошибки линковки библиотеки при автономной сборке. Там где это необходимо, проекты-пользователи должны предоставлять линковщику свои реализации этой функции;
• CT_NO_64 - выключить поддержку 64 битных типов данных.

Инициализация библиотеки

В некоторых случаях не обойтись без выполнения каких-либо действий сразу после загрузки библиотеки, чтобы все её подсистемы работали корректно. Если внешний проект только использует какие-либо простые макросы, то инициализация не нужна. В противном случае рекомендуется вызывать функции из файла ctools.h:

• initializeCtools() перед использованием библиотеки;
• finalizeCtools() после завершения работы с библиотекой (выгрузки динамической библиотеки из памяти или завершения работы программы).

Тестирование

Смотри подкаталог tests.

TODO

• Сборка статической и динамической библиотеки (добавить аттрибуты линковки ко всем внешним объектам);