BSDPORTAL.RU

Здравствуйте!

Пытаюсь освоить настройку CMAKE 3.5.x. Собственно, не столько мой интерес, сколько разработчики LLVM подталкивают. Написали, что уже в 3.8.0 autoconf - deprecated, а с версии 3.9.0 сборка только с помощью CMAKE. Изучение доков по CMAKE не помогло найти ответы на некоторые вопросы (вернее отдельные куски находил, но целостная картинка не собралась). Поэтому прошу вашей помощи. А именно, мне нужно найти аналоги настроек configure в CMAKE:


В идеале - просто для командной строки (не использовать CMAKE_TOOLCHAIN_FILE).

_________________
Обращаюсь на "ты". Если не устраивает - пишите в ПМ, я применю патч :)

Запустите cmake с дефолными параметрами, а потом посмотрите в builddir/CMakeCache.txt или через cmake-gui. Там все переменные есть. Еще есть документация https://cmake.org/cmake/help/v3.5/manua ... les.7.html

arrowdodger, спасибо за наводочку!

Но, увы, нашел частично. Инфы много там получается, возможно опять что то пропускаю. Ткни, плс, куда смотреть. Получился вот такой файл CMakeCache.txt (на форуме ограничения по объему знаков поста не позволяют выложить полностью, поэтому линк на яндекс.диск).

Из него я отфильтровал частично:


Таким образом осталось актуально:

--build=BUILD
--host=HOST
--target=TARGET
--programm-prefix=PREFIX

_________________
Обращаюсь на "ты". Если не устраивает - пишите в ПМ, я применю патч :)

Если это Debug/Release, то это CMAKE_BUILD_TYPE.


Полагаю, CMAKE_INSTALL_PREFIX.


А что они делают?

Увы, не то. См. ниже в цитате описалово.


Описывать долго, я приведу копипасту из доки:



Тоже не то. С помощью --programm-prefix можно задавать префиксы для собираемых программ. К примеру, можно в одном каталоге $HOME/dev/cross/bin поместить ranlib, i686-w64-mingw32-ranlib, x86_64-w64-mingw32-ranlib, и они не будут друг другу мешать (пересекаться по имени).

_________________
Обращаюсь на "ты". Если не устраивает - пишите в ПМ, я применю патч :)

--programm-prefix=PREFIX, можно наверно так
set_target_properties(ranlib PROPERTIES PREFIX "${PROGRAM_PREFIX}")

_________________
Я всегда лгу...

Тогда вместо --build надо читать как делать кросс-компиляцию в СMake, а вместо --host используются условные операторы:



или же https://cmake.org/cmake/help/v3.5/varia ... YSTEM_NAME

build/host/target - это кросс-компиляция, в CMake она сделана по другому: https://cmake.org/cmake/help/v3.5/manua ... ins.7.html
Глобального аналога program-prefix нет, такие вещи обычно реализуются в проектах кастомно, ибо у всех свои представления где и какие нужны префиксы/суффиксы и как они используются.

А вообще не понимаю почему вместо того чтобы плясать от задачи (собрать то-то и так-то CMake'ом) вы зачем-то занялись переносом configure-специфичных флагов.

Долгая история. Ну попробую вкратце. Как получится. Некоторое время назад я заинтересовался языком D. Даже попытался собрать русскоязычное комьюнити по нему. Но, увы, язык не сильно распространен. Хотя язык проектировался как С+++ (еще до С++11), большинство знакомых используют его в каких-то ИМХО "узко-специализируемых" (OpenGL Win only) и порой несвойственных (CMS для web) проектах. Я же хочу получить набор инструментов для кросс-платформенного создания ПО. И у меня есть хороший пример. Под Funtoo Linux я таки собрал для С++ для интересующих меня целей (Win 32/64, Linux 32/64, MacOSX 64, Android-чисто тест). Все это удобным набором интегрировалось в QtCreator. На этой связке я в течение полутора лет весьма успешно и очень удобно разработал и сдал проект госконторе. Заказчик был более чем доволен. Сервак на FreeBSD 9.0+PostgreSQL, клиенты большей части под виндой, приходил проверяющий с нотом под Manjaro Linux x64, получил клиента и офигевал от разнообразия предложенного. В общем все прошло как по маслу. Но это работа ...

С языком D хочу такое же рабочее окружение. Плагин к QtCreator'у уже есть, осталось таки собрать тулчейны. Но загвоздка в том, что выбранный мною компилятор (самый перспективный) LDC, благодаря использованию LLVM, может генерить код под большое количество архитектур и операционных систем. Но создание того, о чем я написал в начале (о тулчейнах) выворачивает мне мозг.

Последовательность нативной сборки:

1) Собираем LLVM (+опционально clang)
2) Собираем DMD
3) Собираем LDC, указывая инсталляции п.1 и п.2 (LLVM точно бэкэнд, роль DMD - пока не знаю, обязательность появилась в последней версии LDC)

Это первый и самый простой шаг. Теперь мне нужно получить туллчейны для x86_64-w64-mingw32.static, x86_64-w64-mingw32.shared, i686-w64-mingw32.static, i686-w64-mingw32.shared (MacOSX,Android,iOS - в планах, как осилю и осознаю). Первая попытка создания была провальной, на сайте мне подсказали кое-чего, но прошло много времени, обновились версии, появилась эта "обязательность DMD". В общем, я опять в непонятках, как и что собирать, в каких форматах должны быть рантайм-либы. А тут еще "сюрприз" от LLVM (типа с версии 3.9 autotools'а больше не будет, только CMAKE). Ну вот я и вернулся к началу :-\

_________________
Обращаюсь на "ты". Если не устраивает - пишите в ПМ, я применю патч :)

Я не до конца уловил что вам надо. Вам нужен кросс-платформенный компилятор D? Для этого достаточно собрать LDC с LLVM, в котором были включены нужные бэкэнды.

В отличие от GCC, компиляторы на LLVM не надо собирать для каждой отдельной архитектуры. Например, clang может компилировать и под свой хост, и под другой таргет одновременно. Из того что я прочел про LDC, он работает так же.


Полагаю, LDC сам написан на D, поэтому для его компиляции требуется собранный компилятор D. Поэтому в пункте 2 не обязательно собирать DMD, достаточно скачать бинарь.

Да.


Вчера это уже уяснил. Нативным clang'ом скомпилировал под x86_64-w64-mingw32, потом линкером x86_64-w64-mingw32.static-ld слинковал exe-файл. Все норм.


Так и есть. Хотя тулзы - частично. А либы на 100%.


Ну эт не проблема, сборка DMD из сырцов у меня около минуты.

Пока в процессе короч ...)

_________________
Обращаюсь на "ты". Если не устраивает - пишите в ПМ, я применю патч :)