Antoniox cmake - Githubissues

antoniox commented 10 years ago

@vuvko @sashafrey Убрал из сборки .pb. файлы, собрал все *.proto вместе.

Проверил у себя на trusty - все ок. А на Windows все еще сборка не идет?

JeanPaulShapo commented 10 years ago

@antoniox Какая версия zeromq и zeromq-devel стоит на trusty (где все ок)?

antoniox commented 10 years ago

Стоят пакеты libzmq3-dev:amd64 и libzmq3:amd64 версии 4.0.4+dfsg-2.

А ты под какой системой собираешься?

JeanPaulShapo commented 10 years ago

Fedora 19. У меня стоит версия 3.2.4 (zeromq3 и zeromq3-devel). Там нет файла /usr/include/zmq.hpp, и поэтому ничего не собирается. Версии поновее (4.x) в стандартных репозиториях нету (точнее, я не нашел). Поэтому хочется получить ответ на вопрос: какая минимальная версия ZeroMQ нужна? Если 4.0.4, тогда надо понять, откуда ее брать для многих систем (как вариант, ручками собирать из tarball'а с оф. сайта).

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

sashafrey commented 10 years ago

Я использовал ZeroMQ 4.0.4, и под Windows и под Ubuntu. Скрипт для установки под ubuntu есть вот в этом makefile: https://github.com/sashafrey/topicmod/blob/master/3rdparty/Makefile

2014-06-23 11:41 GMT+02:00 Nikita Shapovalov notifications@github.com:

Fedora 19. У меня стоит версия 3.2.4 (zeromq3 и zeromq3-devel). Там нет файла /usr/include/zmq.hpp, и поэтому ничего не собирается. Версии поновее (4.x) в стандартных репозиториях нету (точнее, я не нашел). Поэтому хочется получить ответ на вопрос: какая минимальная версия ZeroMQ нужна? Если 4.0.4, тогда надо понять, откуда ее брать для многих систем (как вариант, ручками собирать из tarball'а с оф. сайта).

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

— Reply to this email directly or view it on GitHub https://github.com/sashafrey/topicmod/pull/66#issuecomment-46824140.

JeanPaulShapo commented 10 years ago

@sashafrey @antoniox Сразу прошу прощения за столь большой шум вокруг сборки под Linux) 1) Спасибо за предоставленную информацию, библиотека libzmq замечательно собралась.Только вот собранные пакеты с zeromq-devel (libzmq3-dev и т.д.) версии 4.x есть только для ubuntu и opensuse, а архив с оф. сайта, который скачивается при запуске скрипта из makefile, к сожалению, не содержит zmq.hpp. Видимо, в связи с этим разработчики rpcz заботливо положили в свою папку /include файл zmq.hpp. Поэтому, мне кажется, неправильно удалять его из проекта (тем более, он практически идентичен файлу zmq.hpp, предоставляемому пакетом libzmq3-dev 4.0.4+dfsg-2, который, скорее всего, лежит в /usr/include) 2) Если все-таки не убирать файл 3rdparty/rpcz/include/zmq.hpp, то необходимо понять, как запускать cmake. Лично у меня все заработало с такой командой: "export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig:${PKG_CONFIG_PATH}; cmake -DZEROMQ_ROOT={path_to_topicmod}/3rdparty/rpcz {path_to_topicmod}"

antoniox commented 10 years ago

@sashafrey @vuvko @JeanPaulShapo Очередная правка ветки, утяните плз и проверьте, что теперь у вас все собирается)

Из внешних зависимостей оставил только boost, все остальное положил в 3rdparty.

zmq.hpp действительно в некий момент уехал в другой репозиторий, утянул его.

В итоге взял

https://github.com/jesperes/protobuf-cmake - чисто cmake файлы для сборки protobuf
http://protobuf.googlecode.com/svn/trunk/ - последняя версия protobuf
https://github.com/zeromq/cppzmq - zmq.hpp файлик
https://github.com/zeromq/zeromq4-x - последняя версия zeromq (совместимая с zmq.hpp)
https://github.com/emzeat/google-glog - glog со сборкой cmake

После чего поправил, чтобы в нашу сборку все укладывалось)

Теперь попробую убедиться, что с Windows изменения совместимы - не уверен, что старого солюшена хватит, много всего изменилось.

JeanPaulShapo commented 10 years ago

@antoniox Все собралось! Отмечу, что glog со сборкой cmake в обязательном пордядке требует наличия gflags (скачал из репозитория с помощью команды yum install gflags gflags-devel, Fedora 19). Надеюсь, этот пакет есть во всех дистрибутивах.

antoniox commented 10 years ago

@JeanPaulShapo Да, действительно, не заметил)

@sashafrey Есть хорошие новости со сборкой под Windows - по крайней мере, cmake с указанием путей до буста выдает проект.

Правда, MSVC Express 12 упорно воспринимается cmake как MSVC11 (хотя, может быть, компилятор там такой и стоит). Поэтому буст потребовалось качать под 11, 12й не находит(

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

sashafrey commented 10 years ago

@antoniox Супер! :)

sashafrey commented 10 years ago

@antoniox Я взял последнюю версию antoniox_cmake и собрал с все 3rdparty, libARTM.so и cpp_client помощью CMake под Ubuntu. Просо супер что ОНО работает! :) Открытые вопросы:

пока нет CMakeLists для artm_tests.
internals.pb.[cc,h] генерируются в папке /src/artm, а раньше они были в /arc/artm/core. Насколько сложно переложить их обратно?
internals.rpcz.[cc,h] еще не генерируются. Можно будет и их собирать с помощью CMake? Для этого нужен ./protoc-gen-cpp_rpcz который собирается в папке /3rdparty/rpcz/src/rpcz/plugin/cpp. Комманда для генерации такая: .\protoc.exe --cpp_out=. --rpcz_plugin_out=. .\artm\proto\internals.proto (это под Windows, в Linux аналогично)
ветка antonio_cmake довольно сильно отстал от master; нужно обновить и решить все конфликты
я смог запустить ./cpp_client, но при этом не указал ему путь к libARTM.so. Как он понял, где его искать? Makefiles, сгенерированные CMake, автоматически инсталируют библиотеку в какой-то путь?
сборка под Window. Ты говорил, что если указать пути в boost - оно работает. Но я не разобрался, как это сделать. Напиши, пожалуйста... Используется графический интерфейс cmake? Какие переменные нужно там прописать? Пришли, пожалуйста, несколько скриншотов на sashafrey@gmail.com

Я буду рад подключиться и помочь с какими-то проблемами из этого списка. Можно созвониться по skype и обсудить план действий :)

antoniox commented 10 years ago

@sashafrey =)

Ответы)

тестов просто в моей ветке пока что нет, т.к. не делал rebase/merge, попробую слить с мастером
internals.pb.{cc,h} - проблемы были с тем, чтобы переместить их компиляцию на уровень ниже - в тот момент не знал, как переменные наверх пробрасывать, сейчас уже научился, можно попробовать вернуть все на свои места)
internals.rpcz.{cc,h} не отследил, посмотрю
ну так cmake при генерации скриптов для сборки ищет библиотеки и прописывает соотв. пути к ним (а если они уж при помощи cmake собираются - то и искать их не нужно); попробуй в консоли запустить ldd cpp_client - увидишь, какие динамические библиотеки нужны бинарнику и откуда они берутся
под windows у меня пока только скрипты для сборки генерируются, а дальше куча всего падает, думаю по очереди с каждым разбираться. Запускаю cmake из консоли (из git-bash), делаю следующее (из корня репозитория)

mkdir build
cd build
cmake -DBOOST_LIBRARYDIR="C:/local/boost_1_55_0/lib32... (там одна папка такая)" -DBOOST_INCLUDEDIR="C:/local/boost_1_55_0" ..

и все собирается)

antoniox commented 10 years ago

Наверное, бустовые переменные для Windows пропишу в CMakeLists.txt, чтобы можно было их не указывать все время. Все равно бустовые библиотеки при запуске ставятся в одно и то же место.

sashafrey commented 10 years ago

Я понял почему у меня проблемы - я собирал boost у себя ("bootstrap.bat" & b2), а оказалось проще скачать вот уже собранный boost: http://sourceforge.net/projects/boost/files/boost-binaries/1.55.0-build2/ Теперь и у меня под Windows CMake сгенерировал vs-проекты.

protobuf и zeromq собрались! При сборке glog нужно добавить #define _VARIADIC_MAX 10, иначе visual studio глючит. rpcz пока не собирается.

antoniox commented 10 years ago

Для glog нашел более правильное решение - http://code.google.com/p/googletest/issues/detail?id=412#c11, добавляю на самом верхнем уровне.

У меня на текущий момент собирается

gflags
gtest
весь протобуф и zmq, как и у тебя

Смотрю на glog, он какие-то ошибки выдает.

antoniox commented 10 years ago

@sashafrey В итоге, сейчас собирается "из коробки" ARTM + cpp_client и запускается (без указания PATH, единственная свободная зависимость - буст - подкладывается в bin/BUILD_TYPE, т.е. рядышком к исполняемому файлу), только есть следующие проблемы:

временно выключил логгирование (закомментил все разумное в src/artm/c_interface.cc:EnableLogging), т.к. линковка с gflags каким-то образом протухла..
все собирается только под Release - не разобрался, как при изменении типа сборки в MSVC перегенерировать проект (в cmake от этого пути зависят)

Посторонние проекты могут не собираться, с текущей веткой пока не сливался (хочу чуть ближе к вечеру попробовать), rpcz файлики не научился генерировать(

Просто прорва времени уходит с Windows на то, чтобы правильно слинковаться, т.к. везде в заголовках различные схемы переключения между dllimport/dllexport (какой-то интересный костыль для MSVC линкера, забавно, что в линуксе все срастается само собой))

Поправил по ходу у нас интерфейс немного, не везде были DLL_PUBLIC, вот.

sashafrey commented 10 years ago

Супер!! Вечером попробую на своем компьютере и скажу, как прошло)

dllimport/dllexport Ну, по-моему это полезный костыль) Он позволяет сказать, что экспортировать из .dll, а что нет. Аналогичная фишка есть и в C# (public vs internal http://stackoverflow.com/questions/4182015/internal-vs-public-in-c-sharp). Но из-за этих dllimport/dllexport текущий вариант сборки (в master) чуть-чуть различается в Windows и Linux. В Windows тесты линкуются статически c libartm.lib, а cppclient использует artm.dll. В Linux такого разделения нет - и тесты, и cppclient используют libartm.so (т.е. линкуются не статически, а динамически).

_>Поправил по ходу у нас интерфейс немного, не везде были DLLPUBLIC Ага, но это было сознательно) Если добавить DLL_PUBLIC к классам из cpp_interface.cc то нужно экспортировать и protobuf-сообщения. Это вроде бы как можно, но "легко" этого добиться не получилось и я решил просто не компилироваьт cpp_interface.cc в artm.dll. Вместо этого cpp_interface.cc компилируется вместе с тестами и cpp_client. Так было только под Windows; в Linux cpp_interface компилировался в libartm.so. Нужно ли включать cpp_interface.cc в artm.dll - это вопрос спорный. Я, наверное, даже чуть-чуть против) Два аргумента:

Если включим - прийдётся уже сейчас документировать cpp_interface и гарантировать стабильность этого интерфейса. А на первое время хотелось бы зарелизить только c_interface и python_interface.
В чем-то логично держать в artm_dll только c_interface, и смотреть на cpp_interface лишь как надстройку. _Предложение: давай вообще удалим cpp_interface.сс, и перенесем его содержимое в cppinterface.h? (сделав все методы "inline" - иначе могут вылазить ошибки линковки) Будет header-only интерфейс, как например zmq.hpp.

2014-07-21 13:56 GMT+02:00 AntonioX notifications@github.com:

@sashafrey https://github.com/sashafrey В итоге, сейчас собирается "из коробки" ARTM + cpp_client и запускается (без указания PATH, единственная свободная зависимость - буст - подкладывается в bin/BUILD_TYPE, т.е. рядышком к исполняемому файлу), только есть следующие проблемы:

временно выключил логгирование (закомментил все разумное в src/artm/c_interface.cc:EnableLogging), т.к. линковка с gflags каким-то образом протухла..

все собирается только под Release - не разобрался, как при изменении типа сборки в MSVC перегенерировать проект (в cmake от этого пути зависят)

Посторонние проекты могут не собираться, с текущей веткой пока не сливался (хочу чуть ближе к вечеру попробовать), rpcz файлики не научился генерировать(

Просто прорва времени уходит с Windows на то, чтобы правильно слинковаться, т.к. везде в заголовках различные схемы переключения между dllimport/dllexport (какой-то интересный костыль для MSVC линкера, забавно, что в линуксе все срастается само собой))

Поправил по ходу у нас интерфейс немного, не везде были DLL_PUBLIC, вот.

— Reply to this email directly or view it on GitHub https://github.com/sashafrey/topicmod/pull/66#issuecomment-49596803.

antoniox commented 10 years ago

Ну, по-моему это полезный костыль) Он позволяет сказать, что экспортировать из .dll, а что нет. Аналогичная фишка есть и в C# (public vs internal <http://stackoverflow.com/questions/4182015/internal-vs-public-in-c-sharp>). Часть проблем возникает и из-за того, что при экспорте объекта все ок, а при импорте зачем-то это нужно явно писать.. Казалось бы, линковщик же и занимается тем, что ищет соотв. символы. Зачем ему еще пометки такие?( Но из-за этих dllimport/dllexport текущий вариант сборки (в master) чуть-чуть различается в Windows и Linux. В Windows тесты линкуются статически c libartm.lib, а cppclient использует artm.dll. В Linux такого разделения нет - и тесты, и cppclient используют libartm.so (т.е. линкуются не статически, а динамически). Пытался этого избежать, но как-то не особо получается.. Первоначальная попытка "сделать все SHARED" с треском проваливается..

Саш, а скажи, какие у тебя проблемы возникали с линковкой, почему тесты только статикой шли? Ага, но это было сознательно) Если добавить DLL_PUBLIC к классам из cpp_interface.cc то нужно экспортировать и protobuf-сообщения. Это вроде бы как можно, но "легко" этого добиться не получилось и я решил просто не компилироваьт cpp_interface.cc в artm.dll. Вместо этого cpp_interface.cc компилируется вместе с тестами и cpp_client. Так было только под Windows; в Linux cpp_interface компилировался в libartm.so. Я вот тут пошел напролом (https://groups.google.com/forum/#!topic/protobuf/PDR1bqRazts), поэтому пришлось и DLL_PUBLIC добавлять.

Да, наверное, стоит тогда вынести в отдельный заголовок все.

antoniox commented 10 years ago

Да, на твоей виртуалке все собирается (и текущий проект собран уже), нужно только gz файлики разжать, задать command line и пользоваться)

sashafrey commented 10 years ago

Closed because a clone of this pull request had been merged to master.

sashafrey / topicmod

Antoniox cmake #66