Не подскажешь как именно? Просто это единственное, что мне помешало сборку кутима до конца на qbs перевести (за исключением поиска внешних зависимостей, но это легче довести до ума)
Если быть конкретнее:
а) есть библиотека libboo, она генерирует version.h;
б) есть приложение foo, среди его артефактов есть goo.cpp, который содержит #include <boo/version.h>.
Вопрос — как их подружить? Если:
а) на момент скана version.h еще не существует;
б) поиск хидеров идет только среди глобальных мест (типа /usr/include) и артефактов данного продукта. (Построитель графа зависимостей даже не пытается искать version.h среди артефактов проекта libboo).
В итоге возможна ситуация, когда goo.o будет пытаться скомпилировать до того, как сгенерируется version.h
Да, это возможно) Довольно занятная штука
К слову, игрался с QBS пару месяцев назад, пофиксил там ряд багов, но обломился из-за одного момента — QBS тогда не умел подхватывать в качестве инклудов сгенерированные хидеры из другого продукта, не подскажешь — это уже пофиксили или нет? (На тот момент собирались делать что-то странное с этим, но я так и не понял по рассылке — что именно)
В QBS парсер на си пишется для поиска зависимостей файлов, например для *.c, *.cpp, *.mm файлов ищутся #include директивы, по которым становится понятно от каких header'ов он зависит, чтобы в нужный момент послать его на пересборку
Вся остальная логика (какие указать флаги для компилятора, линковщика и т.п.) реализована уже в QBS модулях (в qml стиле)
1. OTR в ближайших- планах, ждите новостей
2. В чем выражается портирование под FreeBSD? Если только в наличии портов, то обращайтесь к их заведующим, если есть реальные проблемы со сборкой/работой, то к нам
Она при установке ставится в ${DATA_INSTALL_DIR}/desktoptheme/default/icons (он задается в cmake скриптах KDE), по дефолту он сводится к "/usr/share/apps", но в некоторых дистрибутивах этот путь переопределяют мейнтенеры (например в Ubuntu и Fedora DATA_INSTALL_DIR равен "/usr/share/kde4/apps"), что может спровоцировать ненахождение ее треем.
Следует передать верный параметр для cmake во время сборки, если путь отличается от стандартного
а) есть библиотека libboo, она генерирует version.h;
б) есть приложение foo, среди его артефактов есть goo.cpp, который содержит #include <boo/version.h>.
Вопрос — как их подружить? Если:
а) на момент скана version.h еще не существует;
б) поиск хидеров идет только среди глобальных мест (типа /usr/include) и артефактов данного продукта. (Построитель графа зависимостей даже не пытается искать version.h среди артефактов проекта libboo).
В итоге возможна ситуация, когда goo.o будет пытаться скомпилировать до того, как сгенерируется version.h
К слову, игрался с QBS пару месяцев назад, пофиксил там ряд багов, но обломился из-за одного момента — QBS тогда не умел подхватывать в качестве инклудов сгенерированные хидеры из другого продукта, не подскажешь — это уже пофиксили или нет? (На тот момент собирались делать что-то странное с этим, но я так и не понял по рассылке — что именно)
Вся остальная логика (какие указать флаги для компилятора, линковщика и т.п.) реализована уже в QBS модулях (в qml стиле)
2. В чем выражается портирование под FreeBSD? Если только в наличии портов, то обращайтесь к их заведующим, если есть реальные проблемы со сборкой/работой, то к нам
Следует передать верный параметр для cmake во время сборки, если путь отличается от стандартного
Можете сказать конфигурацию SOCKS5 прокси сервера? (Название + версию ПО)