Один маленький проектик

Привет.
Один проект требует обязательного указания опций cmake -DXFILES_DIR=... -DXFILES_ENABLE_UI=1
Чтобы не требовать (и не забывать указание опций) я сделал суррогатный cmakefile.txt где и определяю эти значения:

cmake_minimum_required(VERSION 3.1)

project(my_wrapper)

set(XFILES_DIR /Users/nick/rust/x-files/here CACHE PATH "path to x-files")
set(XFILES_ENABLE_UI 1 CACHE BOOL "enable ui")

Проблема в том, что я не хочу вот так хардкодить абсолютный путь. Есть ли какая-нибудь возможность сделать абсолютный путь из относительного, что-то типа

set(XFILES_DIR abs_path(x-files/here) CACHE PATH "path to x-files")

?

зы: Почему нужен абсолютный путь? Внутри текущего проекта есть такие куски в симейках:

include_directories(
  ../Util/Source
  ../ASIO/src
  ../Config/Source
  ${XFILES_DIR}
)

и если XFILES_DIR не будет абсолютным путём, то он просто не найдёт нужные хедеры.

потому что include_directories() резолвит пути относительно той директории, в которой лежит CMakeLists.txt его вызывающий

Спасибо. Затещу.

Да, спасибо, file(REAL_PATH x-files XFILES_DIR) работает 👍

Истина где-то рядом?)

Да, уже накрыло.

А бывают какие-нибудь утилитки или просто общий алгоритм для того, чтобы перевести sln в cmake? Мне нужно портировать  проект из студии под линукс и как-то не очень хочется ручками писать cmake файл с нуля, т.к. проект не самый маленький

@anatolijs тут люди хотят тот твой легендарный конвертер 🙃

он к сожу только для Visual Studio 6, но кто-то здесь бросал сырцы на гитхабе конвертора из solution в cmake

я опять пришёл спрашивать дичь

как устроен прогон CI на пулл-реквестах в гитхабе/гитхабе/whatever, когда нужно проверить собирабельность результата мержа пуллреквеста? вот буквально — что там под капотом происходит?
я это вижу примерно так:
- гитхаб реагирует на пуш в ветку и делает там мерж в мастер
- если мержконфликт — гуляй вася
- если смержилось — делает некое git branch github-internal-secret-pull123; git serve -p 23456
- ci agent при запуске клонирует вот это временное github.com:23456/repo/github-internal-secret-pull123

прав я, али нет?
Контекст любопытства: размышляю о перспективах велосипедирования своего github actions без гитхаба (не спрашивайте)

Гугл выдает кучу вариантов как сконвертировать солюшен в CMake скрипт. Но с ними надо разбираться. На мой взгляд правильнее будет заморочиться и сделать хороший СМаке скрипт. Мы в начале этого года как раз это делали. Человек примерно через неделю сделал первый скрипт. И тут оказалось, что в наших проектах куча изменений внесенных на протяжении 10-ка лет, о которых мы даже не догадывались. Которые скрывали различные ошибки и тп. В общем это хороший момент на ревью организации проектов, их чистки и тп.
По поводу алгоритма: мы сделали в СМаке некую метафункцию которая декларирует проект (типа шаблона). На входе функции: имя проекта, зависимости и тп. А дальше через эту функцию описали все проекты в солюшене. Также сделали функции для декларации импортов (внешние зависимости, библиотеки и т.п.). Вот пример CMakeList.txt:
—————————-
cmake_minimum_required(VERSION 3.12)

project(VBLNET)

include(../CMake/modules.cmake)

find_package(CURL CONFIG REQUIRED)
find_package(ZLIB REQUIRED)
find_package(OpenSSL REQUIRED)

DeclareModule(PROJ_DEPS VBL
             IMPORT_DEPS CURL::libcurl ZLIB::ZLIB OpenSSL::SSL OpenSSL::Crypto
             IMPORT_DEPS_WIN "crypt32" "Wldap32" "Wininet" "Iphlpapi"
             )

ExportAll()
—————————-
Наверное, что это не бест практик, но это просто, удобно и работает :)

Ты примерно правильно описал.

CI runner без Гитхаба вполне себе имеет право на жизнь. У того же Гитхаба есть даже специальные хуки, чтобы отгружать работу по сборке на самодельный CI.

Вообще, стоило бы перенести вопрос сюда, но сборка через nmake выглядит предельно просто:
mkdir build
cd build
cmake -G "NMake Makefiles" ..
nmake

редактирую)

Недавно возникла странная проблема со связкой CMake+Visual Studio. Винда у меня не основная платформа. Превращаю через CMake свой код в проект студии, который и запускаю с пропертей Release. Загадочным образом, начиная с какого-то обновления студии, бинарники перестали собираться как релизные. У них и сам размер стал меньше, и что важно, скорость исполнения сильно-сильно упала. Как будто, отладочный режим включается (на что намекает какой-то сбой, фиксируемый в логах). В то же время, если открыть проект как проект CMake, а потом собрать через IDE-шку студии как x86-Release, то бинарники пашут быстро, как и было до этого, когда также собирал через консольку. Сборка такая: CMakeLists.txt -> получаю *.sln через cmake -DCMAKE_BUILD_TYPE=Release … -> собираю MSBuild *.sln /p:Configuration=Release. Если что, CMake недавно обновил. Готов перейти на nmake или что-то там сейчас вместо него. Как сделать так, чтобы можно было собирать по-прежнему релизные сборки в винде через консольку (PowerShell / Command Prompt)?

Вариант с nmake пробовал, но с ходу не нашел нужный nmake (сейчас на маке, но винда в буткампе, и могу посмотреть пути)

возможно, что MSBuild у меня был 32-битный, если это на что-то влияет