Минимальный комплект разработчика для POSIX-среды , из-под cygwin на C/C++, используя GCC

Вот встал вопрос о работоспособности наших внутренних утилей под обоими мега-API, как Win, так и POSIX. Подавляющее их большинство не GUIные, а вполне себе консольные. Их я взял на себя. Гуйные будут где-то переноситься на Qt, где-то переписаны с нуля. Их немного, и у нас есть люди, хорошо умеющие Qt.
В связи с этим возник сабж. Утили уже наличествуют в достаточном количестве, но писаны в течение лет эдак 10-и большей частью под Win с MS-ными расширениями языка и библиотек. Моя задача заключается в их окросплатформовании. Дело нехитрое, мои утили большей частью и так переносимы, за исключением внутренностей low-level слоя, не покрываемого стандартными библиотеками. Но. Мне требуется минимальная POSIX-среда для контрольной компиляции и тестирования кроссплатформенности. Прошу виртуалку с никсами на борту не предлагать, это чересчур монументальное решение для такой несложной задачки. В связи с этим есть вопросы.

• Каков минимальный набор пакаджей в cygwin требуется доставить для имения баш-консоли, компилятора gcc/g++ с линкером и библиотекарем, мэйкера без автомэйкера, и может быть gdb (но его отсутствие переживу)? Уж слишком уж дохрена их в полном комплекте, и подавляющая часть не нужна ни разу. X-ы вот точно не нужны. Из библиотек требуются лишь STL и BOOST.
• Насколько сложно в cygwin доставлять новые компоненты и пакаджи (если вообще возможно), которые можно получить в никсах из их репозиториев?
• Насколько (примерно хотя бы, что б оценить трудоёмкость) отличаются процедуры сборки и инсталляции опенсорсовых либ из их сырцов? К примеру, интересует, как под cygwin-ом будет выглядеть сборка новой версии boost-а. Подсказка: вопрос связан с предыдущим, но не эквивалентен ему.

Так же интересуют маны на всё поставленное, меньше буду гуглить.

Qraizer
QNX тоже себя мнит POSIX совместимым. Однако от POSIX поддерживает 1%
Любая OS имеет среду обитания инфроструктуру. И без перекомпиляции программы просто не работают.
Слышал фразу что Cygwin это не POSIX это cygwin. И видимо это правда так как работает только с пакетами из своего репозитария. Впрочем как и большинство ОС, правда ОС ещё иногда позволяют и бинарник запустить, а вот Cygwin только перекомпиляцию.

Цитата Qraizer @ 08.07.14, 15:04

Каков минимальный набор пакаджей в cygwin требуется доставить для имения баш-консоли, компилятора gcc/g++ с линкером и библиотекарем, мэйкера без автомэйкера, и может быть gdb (но его отсутствие переживу)? Уж слишком уж дохрена их в полном комплекте, и подавляющая часть не нужна ни разу. X-ы вот точно не нужны. Из библиотек требуются лишь STL и BOOST.

При установки программ установщик найдёт недостающие пакеты и доставит их. Принцип работы не отличается от репозитариев линуксов.

PS. А cygwin жив? А то лет 5 назад он практически не развивался.

Сообщение отредактировано: Pavia - 08.07.14, 15:59

Цитата Pavia @ 08.07.14, 15:57

QNX тоже себя мнит POSIX совместимым. Однако от POSIX поддерживает 1%

Откуда дровишки?

Добавлено 08.07.14, 18:02

Цитата Pavia @ 08.07.14, 15:57

И видимо это правда так как работает только с пакетами из своего репозитария

И что? РедХат как-то с дебиановскими репозиториями тоже не очень дружит, а с BSD'ями так совсем плохо.

А большего и не надо, Pavia. Мне от POSIX нужна всего-то API-база для LIBC/M, STL и BOOST. Пересборка предусматривается как необходимый процесс, при этом поддержка мульти-никсов не нужна совершенно, достаточно простых makefile без auto. За сторонние пакеты и библиотеки я упомянул на случай, если вдруг в будущем потребуются, ибо найти готовое обычно проще, чем писать самостоятельно. В частности сам boost при необходимости может быть сконфигурирован для использования других, сторонних по отношению к нему, библиотек. Фактически сейчас у меня только одна тулза, моего авторства, кстати, использует API-зависимый класс с синопсисом

template <>
class API_Proxy<USED_API>: API_Proxy_Base
{
public:
   API_Proxy(const tstring& dir, const tstring& file);
  ~API_Proxy();
 
  const tstring& get() const;
  void peek();
 
  operator SafeBoolCast API_Proxy::*() const;
  API_Proxy_Base::state state() const;
};

чтобы перебирать файлы по вилдкарду. Легко заменяется на boost::filesystem, но стоит ли? Писалось без оного, и POSIX часть просто не отлажена.

Ответ на первый вопрос в общем-то необязателен. Сетапер позволяет при необходимости доставлять требуемое, вопрос только в том, чтобы это самое требуемое знать, как называется, и в какой категории его искать. Сейчас итеративно поставил gcc/g++ + bash + make + mc + libstdc++ + boost 1.48. Вроде чухает как-то. Ответ на остальные два вопроса я в общих чертах получил, и они мне не понравились. Получается, что готовых рецептов нет, без ручной курения не обойтись, и не факт, что оно даст результат, если только нужного пакета не окажется в репе самого cygwin-а.

Цитата Qraizer @ 08.07.14, 15:04

Каков минимальный набор пакаджей в cygwin требуется доставить для имения баш-консоли, компилятора gcc/g++ с линкером и библиотекарем, мэйкера без автомэйкера, и может быть gdb (но его отсутствие переживу)?

Недавно устанавливал как раз, вроде просто Далее нажимаешь (т.е. дефолт), он как раз этот минимум и поставит (ну может еще кой-чего).

Цитата Qraizer @ 08.07.14, 15:04

Из библиотек требуются лишь STL и BOOST.

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

Цитата Qraizer @ 08.07.14, 15:04

Насколько сложно в cygwin доставлять новые компоненты и пакаджи (если вообще возможно), которые можно получить в никсах из их репозиториев?

У каждого дистрибутива и тем более ОСи свои репозитории (+/- вариации). У цигвина соответственно тоже свои, чего не хватит, придется руками собирать.

Цитата Qraizer @ 08.07.14, 15:04

Насколько (примерно хотя бы, что б оценить трудоёмкость) отличаются процедуры сборки и инсталляции опенсорсовых либ из их сырцов?

Отличаются от чего? Если совсем "сыро", то

$ ./configure --prefix=/D:/hell/lib && make && make install

, только префикс для конфигура указать, куда устанавливать. Лучше отдельный от цигвиновских либ каталог, чтоб не смешивать пиво с водкой.
Ну и переменную окружения например задать соответсnвенно (LD_PATH, кажется), так что по сути пофиг куда складывать. Впрочем, это я на практике не пробовал.

Цитата Qraizer @ 08.07.14, 15:04

Так же интересуют маны на всё поставленное, меньше буду гуглить.

К пакетам, установленным из цигвина, маны ставятся в нем же (вроде отдельная категория, точно не помню).

Сообщение отредактировано: korvin - 08.07.14, 18:16

Цитата Qraizer @ 08.07.14, 15:04

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

В лучших традиция русского форума предложу именно этот вариант Ибо бубен с cygwin грозит перерастанием задачи из несложной в сложную.

Цитата MyNameIsIgor @ 08.07.14, 18:16

В лучших традиция русского форума предложу именно этот вариант Ибо бубен с cygwin грозит перерастанием задачи из несложной в сложную.

++. Тем более раз гуй не нужен, можно виртуалке минимум ресурсов дать, чтоб не мешала. Разве что компилить будет долго. =)

Цитата korvin @ 08.07.14, 18:14

Отличаются от чего?

Ну я как бы не рассчитываю, что выкачав с джита некое нечто, просто так возьму и запилю автомэйк+инсталл, вряд ли там искаропки будут cygwin-овые цели. Однако раскурить, как оно там внутри, и перенести соответственно на имеющуюся реаль cygwin-на можно постараться. Не факт, что получится, ибо вероятны требования наличия дополнительных пакаджей или либ, и не факт, что эта рекурсия где-нибудь свернётся.

Цитата MyNameIsIgor @ 08.07.14, 18:16

В лучших традиция русского форума предложу именно этот вариант

Этот вариант я попросил не рассматривать не потому, что не подходит, а потому, что я о нём знаю, и говорить на его тему тут нет смысла. Если крайне потребуется что-то, для чего cygwin-на будет недостаточно, безусловно этот вариант и будет запилен. Но сейчас в этом нет необходимости.

Цитата Qraizer @ 08.07.14, 15:04

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

Цитата MyNameIsIgor @ 08.07.14, 18:16

В лучших традиция русского форума предложу именно этот вариант Ибо бубен с cygwin грозит перерастанием задачи из несложной в сложную.

+1

Поскольку в основном только и приходится делать, что собирать кроссплатформенные компоненты и валидировать их сборку под разными платформами, то по вопросу могу сказать следующее:
1. На Win-платформе с помощью MinGW + MSys проверяешь, что с помощью gcc и минимальным набором posix-заголовков всё собирается. MSys нужен для эмуляции башовской консоли и возможности запуска autoconf/automake.
2. На Lin-платформе собираешь финальную posix-версию утилиты, и тестируешь что всё собирается именно под Linux, и, главное, работает.
ИМХО, только так. После вычистки основных платформо-зависимых косяков тебе останется только время от времени толкать сборки под разные платформы и фиксить возникающие проблемы с компиляцией (если вообще возникнут).

Flex Ferrum, ещё раз говорю, мне не нужна кроссплатформенность по самое немогу, использоваться будет только STL и может быть иногда BOOST. На таком уровне вся кроссплатфоменность и так будет искаропки. Вопрос только в том, что не всё может быть покрыто этим уровнем абстракции, и следовательно некий LL-слой кода может потребовать явного использования API ОСи. Упоминание пакаджей вообще и сторонних либ в частности было мною сделано, потому как все прекрасно понимают, что ТЗ имеют склонность к изменению в неподходящие моменты, и мне нужно быть к этому как-то готовым, чтоб сразу аргументами с цифрами разъяснить политику партии.

Qraizer, тогда есть такой вот вариант: сделай define _WINDOWS_H в настройках компиляции, и собирай под тем же MinGW. У тебя тут же всплывут все исходники, которые так или иначе включают windows.h.

Сообщение отредактировано: Flex Ferrum - 09.07.14, 13:18

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

Цитата Qraizer @ 09.07.14, 13:45

Ну ведь проблема не ограничивается только лишь поиском непортабельности. Её надо будет устранить и проверить, что она устранилась.

Такая неработоспособность устранятся двумя способами, как ты понимаешь:
1. Выпиливанием функционала;
2. Использованием кроссплатформенного функционала;
3. Взятием под #ifdef.

Следовательно, тебе надо будет только лишь выявить файлы, где используется win-specific функции, и привести эти файлы к компилируемому виду под MinGW. В идеале, у тебя всё должно работать под виндой. Чистый posix я бы всё-таки тестировал под Linux и только под ним.

Сообщение отредактировано: Flex Ferrum - 09.07.14, 13:49

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

P.S. К тому же там задействован не только и даже не столько виндовый функционал, сколько MS specific. Это тоже выпиливать надо будет. Это я к тому, что одним лишь windows.h всего не отдетектить.

Сообщение отредактировано: Qraizer - 09.07.14, 15:34

Цитата Qraizer @ 09.07.14, 15:34

сколько MS specific

Об MS-specific у тебя gcc споткнётся. Если, конечно, ты не библиотеки имеешь ввиду.

Цитата Qraizer @ 09.07.14, 15:34

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

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

Более того, готового валом.

Скрытый текст

пример