Очень долгое время придерживался подхода, когда в C++ном проекте исходники всех зависимостей включаются прямо в дерево каталогов самого проекта.
Возьмем, для примера, наш проект arataga (его рассматривать интереснее, чем RESTinio или so5extra, т.к. это не библиотека, а вполне себе законченное приложение, хоть и небольшое). Сам проект содержит всего два подкаталога с исходниками:
arataga/
`- arataga/ # Здесь сами исходники проекта.
`- tests/ # Здесь исходники тестов.
Понятное дело, что этих двух каталогов недостаточно для сборки проекта. Нужно подтянуть исходники. В arataga это делается через наш собственный велосипед, но суть не в использованном велосипеде, а в том, что после подтягивания зависимостей подкаталогов станет побольше:
arataga/
`- arataga/
`- args/
`- asio/
`- doctest/
`- fmt/
`- ...
`- tests/
Соответственно, все это добро будет компилироваться вместе с проектом.
Допустим, я взял конкретную версию arataga и собрал ее в одном каталоге. А затем захотел взять и собрать в другом каталоге другую версию. B этом другом каталоге мне опять нужно будет получить все зависимости и скопилировать их там вместе с aragata. Полная компиляция потребуется даже если сами по себе зависимости остались точно такими же.
Полная компиляция всех зависимостей вместе с проектом -- это неоднозначная штука. Есть свои плюсы и свои минусы.
Однако, ручное управление зависимостями в C++ проектах посредством собственных велосипедов уже уходит в прошлое. У нас есть и vcpkg, и conan, которые берут на себя все эти заботы. И, вроде бы, волосы (у кого они еще остались) должны стать мягкими и шелковистыми...
...Но вот в текущем проекте, где мы задействовали vcpkg и избежали изрядного геморроя со сборкой ffmpeg и SDL2 на разных платформах, довелось столкнуться с неудобством, о котором раньше не приходилось задумываться.
Для разбирательства с внезапно обнаружившимся дедлоком захотелось вставить отладочные печати в исходный код библиотеки, которая подтягивалась через vcpkg.
И тут-то я понял, что не представляю, как это сделать.
Исходники-то библиотеки лежат где-то под контролем vcpkg. В каких-то вспомогательных каталогах. И даже если внести в эти исходники свои правки, то у меня нет понятия о том, как же заставить vcpkg перекомпилировать модифицированную зависимость. Т.е. vcpkg считает, что все собрано и помещено куда следует, поэтому в перекомпиляции нет надобности.
В общем, то, что я всегда проделывал раньше даже не задумываясь ни о чем, сейчас с vcpkg стало внезапной головоломкой.
Какое будет резюме?
Наверное вот такое: много-много лет пользовался собственными инструментами, которые позволяли жить в логичном и комфортном мире, где все понятно, удобно и настроено под себя.
А сейчас пытаешься подстроится под то, что считается типа мейнстримом... И возникает ощущение, что все это придумано инопланетянами для рептилоидов. И непривычно, и не всегда понятно, и далеко не всегда удобно.
PS. Писал про aragata и испытал приступ ностальгии. С удовольствием бы пропрограммировал бы сейчас что-нибудь подобное, а то приходится заниматься направлением, к которому душа не лежит :(
Интересно, а на gradle/bazel не посматривал?
ОтветитьУдалить@goncharenko:
ОтветитьУдалитьТребование использовать CMake шло от заказчика. А vcpkg уже мы подтянули, когда забабахались со сборкой ffmpeg под Windows.
Действительно, в этом плане vcpkg несколько примитивен. Тот же conan позволяет локально взять одну из зависимостей в состоянии editable и билдить/дебажить в составе мастер проекта. (Правда в компании используем свой допиленный конан).
ОтветитьУдалить@SiGMan
ОтветитьУдалитьВ vcpkg, в принципе, я могу подменить portfile и указать на локальную копию нужного проекта.
Conan не стали брать потому, что на тот момент там не было нужных нам проектов, тогда как в vcpkg они были. А опакечивать что-то самому для Conan-а, как по мне, так удовольствие то еще. Разрабы Conan-а развивали его так быстро, что за модификациями я лично очень быстро устал следить.