посоветуйте как лучше/проще трекать зависимости кроссплатформенного проэкта?

Хотелось бы уточнения, лично не непонятно, что нужно.

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

Проще прямо в репозитории

За это в приличном обществе руки ломают.

Я сказал проще, а не правильнее )

Правильно писать «прожект».

мож быть. я не так давно русский выучил.

например моя система сборки должна знать установлена ли а если установлена то где libftdi, libxml2, zlib и прочее. Под линуксом я имею pkg-config ну и autotools на хужий случай.

а что делать под форточками? вопрос возник из того что компилять это скорее всего будут студенты с IQ ниже среднего. вероятно хардварщики. хорошо что не гуманитарии.

Так Windows он же тоже разный бывает.

Под линуксом я имею pkg-config ну и autotools на хужий случай.

В Msys (который с MinGW) и Cygwin есть как минимум sh, то есть autotools как-то будут работать

компилять это скорее всего будут студенты с IQ ниже среднего

Наговариваете, наверное?

Ну вот я видел три подхода:

- таскают библиотеки с собой, но ./configure(например) пытается найти системную библиотеку. И в зависимости от версий решает какую использовать

- пишут README в котором рассказывают как установить библиотеки и слинковаться с ними

- выкладывают библиотеки в виде заголовков и бинарников, или даже завернутые в инсталлятор (как правило для MSVC)

Возможно, в последнее время появились какие-то облегчающие инструменты, но что-то сомнительно

использовать cmake

Использовать cmake, проверку делать:

FIND_PACKAGE(PkgConfig)
pkg_check_modules(SYSTEM_ZLIB zlib>=0.x.x)

или так, но это очень примитивно и не сработает если имя файла отличается между дистрибутивами, привет тем рпмщикам кто выкидывает главную ссылку на либу.

find_library(SYSTEM_ZLIB_FOUND z)

Если в devel пакете нету libz.so ссылки на libz.1.1.1.so - этот способ не взлетит.

Под виндой 95% слуаях все свои 3rdparty нужно таскать с собой, все собирать, линковать или с бинарником или статитически с какой-нибудь main бибилиотекой пограммы.

Под маком тоже самое как и в винде, правда в системе тоже есть из коробки по мелочи протухших либ. Использовать из macports, homebrew и затем копировать себе в DMG выправляя пути otool, не рекомендую, так как нужно будет постоянно проверять сборку и работу на обновленных библиотеках. (Если скрипты сборки распространяются)

например моя система сборки....
... а что делать под форточками?

просто поверь, никому «твоя система сборки под все платформы» не интересна. 99% пользователей форточек, которых заинтересует твой продукт (подставь здесь сам цифру в процентах), использовать будут бинарную сборку.

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

Сумбурно написал, но вот например, последний случай, присылают мне патч на webos в нем также кроме основных define ещеотдельно файл webos_libintl.h. Так вот разработчика абсолютно не должно волновать что под webos нет libintl по умолчанию и т.п. Кому надо соберет себе toolchain со всеми зависимостями без всяких вопросов.

Вот, кстати, почитав cmake-евангелистов, решил его попробовать. Достаточно простй проект, pure C, внешние библиотеки libevent, OpenSSL.

Хотелось покрыть хотя бы 3 платформы: Linux, *BSD и MinGW. Везде gcc, вроде как должно быть просто. Но нет.

В cmake оказалось реально мало проверок искаропки. То что libevent может состоять из core и extra (как в OpenBSD) он не знает. OpenSSL в том же OpenBSD тоже сразу не нашел, пришлось подсказывать. Пути в которые ставит MSYS по make install он тоже не умеет, опять надо руками. То есть получается очень условная такая полезность: все равно для каждой платформы нужно свой набор писать. Так это еще фактически и не разные платформы, а одна. Подозреваю что для icc, msvc еще веселее, не говоря уже о всякой экзотике