о менеджере пакетов замолвите слово?

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

Ищу менеджер пакетов, ну или хотя бы систему построения проекта.

1. простой синтаксис.
2. возможность задавать разные компиляторы. Желательно самый минимум от "gcc" до "msvc".
3. работоспособность на разных платформах от "unix" до "windows".

Хотелок вообще-то гораздо больше. Неуверен, что обозначил все.

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

Следующая мысль это скрипт для коммандной оболочки. Если для себя и для единственной конкретной платформы, то уже вполне нормально.
Но вариант трудно настраиваемый и принципиально непереносимый. Угу, я даже и не пытался переносить "cmd" из "windows", на "bash" под "free bsd".

Впрочем, как вариант, написать велосипед на "python", "rubi", "perl" или даже "php".
Это уже реальнее, но велосипед есть велосипед.
Полезут косяки, многое придётся переделывать.
А главный недостаток в том, что этих самых интерпретаторов может и не быть на целевой машине.

Далее "makefile". Если не ошибаюсь, то он придумывался как замена таким вот универсальным скриптам.
И всё бы хорошо, но есть несколько проблем.
Синтаксис у него кривой, сложный и запутаный.
Сам файлик получается очень уж большой и мудрёный. Помоему слишком много лишнего, особенно если писать руками.
И самое убийственное, в том, что некоторые конструкции плохо переносятся. Банально, "mingw make" несовместим с "microsoft nmake".

Можно сделать генератор этих самых "makefile". Пусть для разной платформы будут разные...
Колупал "auto tools" и получил травму головного мозга. Это страх и ужас. Особенно под windows. Да и синтаксис заковырист.
Колупал "cmake", уже гораздо лучше, но всё равно какая-то хрень получается. И входной формат неудачный и документация запутанная.

Тут мне подумалось, что нафиг "makefile", можно генерировать прямо скрипты командной оболочки.
Упс, неожиданно, вообще ничего ненашёл.
Стал изучать тему подробнее, с мыслью написать самому генератор. Но обнаружил огромную кучу этих самых командных оболочек и решил не связываться с ними. Действительно, делать совместимость со всеми оболочками, идея весьма глупая.

А вообщем-то скрипты нам не нужны. Программа прекрасно сможет сома запускать всякие компиляторы и прочую лабудень. Посчастью с этим у C++ хорошая переносимость. Главное, чтоб программу скомпилировали на нужной платформе.
Но перерывая информацию, всё равно, ничего достойного не нашёл.
У "rust" есть например "cargo". Но там этот rust прибит гвоздями и хрен заменишь.

Так почему же ничего подобного нет для "C++"?

Народ! В самом деле нет? Или я прошёл мимо?
У меня третий день ломка из-за этой фигни. Мой "makefile" не хочет запускаться, с конфигурированием "cmake" сожрал пуд соли. Сижу, плююсь аки верблюд.

Руки чешутся сесть и наваять велосипед. Но я очень плохо знаком с *nix.

boost build

Цитата Qraizer @ 02.08.16, 23:26

boost build

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

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

А теперь печалька.
"-bash: bjam: command not found"
В том смысле, что на чужом удалённом сервере, придётся извращаться, чтобы подсунуть boost build.
Вродебы упоминалось, что его можно прицепить прямо к пакету. Но это уже сложнее, придётся курить маны.

Сам буст собирается этим bjam-ом. Который собирается скриптом в корне распакованного буста.

Посмотрите https://conan.io
Мы пользуемся в связке с qbs.

А в чем проблема? Какую задачу хотите решить? Не совсем понятно)

Если нужна кросс-компиляция, то я собираю прям из IDE (CodeLite) штатными средствами без какой либо магии и документации. Просто создаешь новую конфигурацию, указываешь компилятор и специфичные флаги (если нужны) и все, F7 и поехали.

Цитата HardRock @ 08.08.16, 13:34

А в чем проблема? Какую задачу хотите решить? Не совсем понятно)

Самая ближайшая конкретная задача:
1. разработка и вылизывание проекта под windows.
2. конечная установка и компиляция под freebsd.

Я сейчас склоняюсь к самому простому решению - написать свой конфигуратор создающий makefile.

Цитата Eric-S @ 08.08.16, 16:03

Я сейчас склоняюсь к самому простому решению - написать свой конфигуратор создающий makefile.

Вот поверь, проще в CMake разобраться.

Цитата Flex Ferrum @ 08.08.16, 16:11

Вот поверь, проще в CMake разобраться.

Тут вылезает чрезмерное применение средств. Весьма близко к выражению "из пушки по воробьям".
Да, я могу заюзать cmake, bjam или conan.
Но вопрос в том, будут ли они на конечной системе? А ставить тяжеловеса, для сборки более простого покета, это лишняя морока.
Более-менее, я могу расчитывать на make и autotools. Но они излишне заморочены.
Впрочем, если ставить вопрос ребром: использовать только какой-нибудь стандартный сборщик, то по видимому остаётся только autotools.

Поднимая эту тему, я надеялся, на какое-нибудь более простое решение. Мне почему-то казалось, что должен быть некий стандартный инструмент, который сделает всё быстро и автоматически.

Сообщение отредактировано: Eric-S - 08.08.16, 19:23

Цитата Eric-S @ 08.08.16, 19:21

Поднимая эту тему, я надеялся, на какое-нибудь более простое решение. Мне почему-то казалось, что должен быть некий стандартный инструмент, который сделает всё быстро и автоматически.

Windows и *nix - очень разные системы. Стандартного общего у них очень мало - только, считай, команды шела, и то синтаксис разный. Поэтому выхода два - либо ставить внешний утиль сборки (типа cmake), либо разносить скрипты сборки по целевым системам. К примеру, для win - пришешь на vbs, для FreeBSD - autotools+make

Цитата JoeUser @ 09.08.16, 04:54

К примеру, для win - пишешь на vbs, для FreeBSD - autotools+make

Влом два раза делать одну и ту же работу. Понятно, что какую-то часть придётся дублировать.
Но тут вообще, пришла забавная идейка. Написать на C++ простенький конфигуратор makefile.
Он компилируется каким-нибудь примитивным скриптом из консоли и тут же запускается.

config.sh

c++ -o build.exe build.cpp
./build.exe $* project.cfg
rd build.exe

Упростить этот build.cpp до полной упоротости. Пусть главное создаст makefile.
А инфу занести в project.cfg

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

Единственное, пока не определился с форматом этого самого project.cfg.

Наверное, проще всего, пихнуть туда шаблончик makefile. А простым поиском и заменой ключевых слов, подставить значения переменных.

Цитата Eric-S @ 08.08.16, 19:21

Цитата Flex Ferrum @ 08.08.16, 16:11

Вот поверь, проще в CMake разобраться.

Тут вылезает чрезмерное применение средств. Весьма близко к выражению "из пушки по воробьям".
Да, я могу заюзать cmake, bjam или conan.
Но вопрос в том, будут ли они на конечной системе? А ставить тяжеловеса, для сборки более простого покета, это лишняя морока.

Ну ёлки-палки, поверь лучше знающему человеку. Пока-что это больше на попытки оправдать своё нежелание учить.

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

Разобраться таки с cmake, bjam, conan, cons, scons или что там приглянется. Пользователи даже спасибо скажут.

Чтобы конечный пользователь мог собрать проект, ему обычно дают инструкцию, в которой предоставляют полный набор инструкций как собрать, включая установку системы сборки (большенство из них уже есть в репозитории). Вот, к примеру: https://github.com/negram/kopete_mrim/blob/master/README

Но! Гораздо лучше с точки зрения пользовательского экспириенса (интересно, до сюда кто-нибудь вообще дочитал?), собрать всё самостоятельно, у себя в виртуалке, загнать в пакеты и дать пользователю готовый пакет. Да, во FreeBSD тоже есть пакетный менеджер.

Добавлено 09.08.16, 06:21

Цитата Eric-S @ 08.08.16, 19:21

Впрочем, если ставить вопрос ребром: использовать только какой-нибудь стандартный сборщик, то по видимому остаётся только autotools.

Даже autotools может отсутствовать в целевой системе. Хотя, если говорить о Фряшечке, это скорее редкость.

Цитата negram @ 09.08.16, 06:19

Ну ёлки-палки, поверь лучше знающему человеку. Пока-что это больше на попытки оправдать своё нежелание учить.

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

Ха-эм... Исходя из этой логики, правильнее всего будет учить autoconf и automake.
Они, судя по всему, более адаптированы к разным платформам и вызовут меньше всего сложностей у конечного пользователя.
Ну что же... Придётся попробовать взятся за них со всей серьёзностью.
Нежелание учить тоже присутствует. Но ведь дибильный синтаксис же!

Сообщение отредактировано: Eric-S - 09.08.16, 06:40

Цитата Eric-S @ 09.08.16, 06:39

Они (autoconf и automake), судя по всему, более адаптированы к разным платформам и вызовут меньше всего сложностей у конечного пользователя.

Это утверждение не совпадает с моим мнением

Добавлено 09.08.16, 07:26
Но это лучше, чем писать свой конфигурятор

Цитата Eric-S @ 09.08.16, 06:39

Цитата negram @ 09.08.16, 06:19

Ну ёлки-палки, поверь лучше знающему человеку. Пока-что это больше на попытки оправдать своё нежелание учить.

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

Ха-эм... Исходя из этой логики, правильнее всего будет учить autoconf и automake.
Они, судя по всему, более адаптированы к разным платформам и вызовут меньше всего сложностей у конечного пользователя.
Ну что же... Придётся попробовать взятся за них со всей серьёзностью.
Нежелание учить тоже присутствует. Но ведь дибильный синтаксис же!

Нет. autoconf и automake - это Unix-way. На винде их (нативных) нет. А вот cmake - есть. Да и сама эта тулзовина довольно популярна. В изучении - относительно проста. По фичам... Ну, свой декларативно-императивный язык программирования. Под BSD стопудово есть порт. Так что... Не занимайся церебральным сексом, используй то, что уже работает.

Я всё равно за bjam

Цитата Qraizer @ 09.08.16, 09:32

Я всё равно за bjam

Ну, не знаю. Экзотика это. Я его кроме буста нигде больше не видел. А CMake - одно из самых распространённых средств.

Твоя программулина:
* использует актуальные хидеры ядра?
* использует множество специфичных версий библиотек (нестандартных для системы и несовместимых между собой)?
* требует пересборки при обновлении системы?
* использует или зависит от специфичного набора команд процессора (и не заведется на другом)?

Если нет - распространяй бинари. Всем от этого проще.

Цитата HardRock @ 09.08.16, 14:50

* использует множество специфичных версий библиотек (нестандартных для системы и несовместимых между собой)?
* требует пересборки при обновлении системы?

Да и в этих случаях, проще со статическими бинарями