Подготовка open source софта к дистрибьюции

Допустим, я написал калькулятор. Архитектура следующая:

[console]
---| back-end |--------
| ------------ |
| libcalc |
| |
| |
| |
| front-end 1 | | front-end 2 |
--------------- ---------------
calc-cli calc-gui
[/console]

libcalc - динамическая библиотека, представляет набор математических функций, которые будут вызываться front-end'ами (например, сложение и вычитание).
calc-cli - интерфейс командной строки. Работать может, например, так: ./calc-cli 1 + 2.
calc-gui - графическая оболочка, окно с кнопками.

Таким образом, мой проект представляет собой три архива с исходными кодами, сборка каждого основана на autotools.

Дальше я подготовил бинарные пакеты для разных Unix и Linux систем. Например, для Debian у меня получилось бы четыре пакета:

libcalc - копирует библиотеку в /usr/lib/libcalc.so.0.0.1 (+ ссылки на неё), позволяет запускать calc-cli и calc-gui, которые динамически связываются с ней и вызывают её функции.

libcalc-dev - копирует заголовок /usr/include/calc.h, нужно лишь для тех, кто будет из исходников собирать front-end'ы.

calc-cli - копирует /usr/bin/calc-cli
calc-gui - копирует /usr/bin/cacl-gui

Теперь, главное. Весь написанный код является кросс-платформенным, а потому я хочу сделать его доступным для систем Windows.

1) Как это вообще будет выглядеть для пользоваталей? Скачивание трёх бинарных пакетов (libcalc-dev опционален, его не считаем) для GNU/Linux - это нормально, но как это организовать для Windows - делать несколько инсталляторов, которые народ будет по очереди запускать? Как это делают другие? Делать один общий инсталлятор я не хочу, потому что нарушатся изначально задуманные гибкость и красота.

2) Как поступать с пакетом libcalc-dev, т.е куда копировать нужный заголовок calc.h в Windows?

3) Как предоставить возможность собрать софт из исходников для пользователей? Положить в корень каждой программы заранее созданный файл проекта Visual Studio? Сможет ли тот сгенерировать libcalc.dll? С другой стороны, autotools может собирать мэйк-файлы для Windows - т.е ему придётся качать, минимум, MinGW и make?

Опыта в сборке пакетов для распространения не имею, поэтому все мои заключения умозрительны
0) Зачем исходники в 3-х пакетах, ведь это части одного проекта. ИМХО проще и красивее запихнуть всё в один и через ./configure управлять сборкой. Вообще дайте представление, о том каких размеров ваш калькулятор. Лимит размера, когда нужны отдельные пакеты можно принять за 100 000 строк(взят с потолка).
1) для windows достаточно одного инсталятора и галочками выбирать, что ставить.
2) В винде обычно это отдельная папка для каждой библиотеки, которую определяет сам программист. Посмотрите, как ставится кьют, qwt или другие либы...
3) Сомнительно, что кто-то будет этим заниматься кроме вас и того, кому придёт в голову собрать инсталятор, а он уж разберётся и найдёт способ... Хотя если заботится обо всех, то вендокодерам приятней всего будет пользовать cmake.

ЗЫ: чего-то тема про маздай получилась)))) хотя на винфаке на такие вопросы вряд ли ответят smile

0) Зачем исходники в 3-х пакетах, ведь это части одного проекта. ИМХО проще и красивее запихнуть всё в один и через ./configure управлять сборкой. Вообще дайте представление, о том каких размеров ваш калькулятор. Лимит размера, когда нужны отдельные пакеты можно принять за 100 000 строк(взят с потолка).

Планируется, что front-end'ы будут писаться другими разработчиками, это всё разные продукты.

2) В винде обычно это отдельная папка для каждой библиотеки, которую определяет сам программист. Посмотрите, как ставится кьют, qwt или другие либы...

ОК, спасибо. Common Files подходит?

3) Сомнительно, что кто-то будет этим заниматься кроме вас и того, кому придёт в голову собрать инсталятор, а он уж разберётся и найдёт способ... Хотя если заботится обо всех, то вендокодерам приятней всего будет пользовать cmake.

С самостоятельной сборкой под Windows всё действительно тяжко. Кажется, придётся писать длинные инструкции: скачайте Cygwin или MSYS, скачайте MinGW, доп. либы, может возникнуть куча проблем разного характера.