конвертировать ./configure в cmake

А смысл? Это ж выхлоп autoconf, ЕМНИП - прошлый век!

Нет. Придётся писать CMakeLists'ы самому.

а зачем, могу я поинтересоваться?

Нет. Придётся писать CMakeLists'ы самому.

Очень жаль(.

Вот ещё. Там вроде есть про то, как переехать с autoconf на cmake

http://www.cmake.org/Wiki/CMake#automake.2Fautotools.2Fautoconf

Было бы неплохо написать такую штуку, хотя бы для генерации работоспособного «первого приближения». Тогда можно было бы выпиливать autohell в масштабах дистрибутивов :)

но не из самого configure конечно:)

а зачем, могу я поинтересоваться?

Ну, на сколько я понимаю, еще много библиотек, которые есть под linux, но которых нет под вынь.
Например, GSL. На сколько я нагуглил, есть какие-то довольно старые порты, хотя, предполагаю, что она вполне крос-платворменна.
Да и так, из интереса)

ИМХО, таких средств уже дофига. Только глубоко неумные люди будут создавать новый проект с autosomething

>Ну, на сколько я понимаю, еще много библиотек, которые есть под linux, но которых нет под вынь.

Для этого необязательно менять систему сборки

Возможные сценарии:

1) Кросс-компиляция: ставишь CC=your-mingw-gcc CXX=your-mingw-g++ и компилишь. Если есть сторонние зависимости, все усложняется

2) Винда+msys

3) В MSVC импорт исходников в новый проект

>ИМХО, таких средств уже дофига.

Я не всттречал. Приведи хотя бы одно, плз)

>Например, GSL

http://gnuwin32.sourceforge.net/packages/gsl.htm

или ты не про то?

>Только глубоко неумные люди будут создавать новый проект с autosomethin

Или гномеры (WebKitGtk на автолулзах!)

пардон, пропустил ссылку

Ну хотя бы тот же cmake. Там CMakeLists.txt для простого проекта менее, чем за минуту можно составить. Не автоматически, но всё же. +у Qt есть своя приблуда, там ещё проще (ну ясное дело, оно ведь только для Qt;), scons.

Например, GSL

http://gnuwin32.sourceforge.net/packages/gsl.htm

или ты не про то?

Именно про то - там последний релиз за 2006 год, когда под линух: «The current version is GSL-1.14. It was released on 11 March 2010.»

>http://www.cmake.org/Wiki/CMake#automake.2Fautotools.2Fautoconf

хотеть: 1) 100% работоспособность из коробки, пусть ценой неоптимального кода внутри и/или дополнительных модулей в CMake; 2) поддержку некдеешного софта

думаю, кросс-компиляция будет оптимальным вариантом в этом случае

>Там CMakeLists.txt для простого проекта менее, чем за минуту можно составить

ага, сделать глоб *.c *.cpp :))

проблема в том, что много сложных проектов на автолулзе

А на сколько сложно такую штуку забомбить (я про конвертер)?
Может разработчикам пожаловаться)?

>А на сколько сложно такую штуку забомбить (я про конвертер)?

Если хорошо знать автотулз и cmake, то думаю не так уж сложно

Может разработчикам пожаловаться)?

Разработчикам GSL или autotools бессмысленно, у них это не лечится

Разработчикам CMake это тоже не нужно, они CMake пилят исключительно для своих проектов

> хотеть

Я тоже)

> Только глубоко неумные люди будут создавать новый проект с autosomething

У autotools есть богатый набор тестор на m4/sh. Часто эти тесты ставятся прям с программой, собранной/сконфигурированной autotools. В случае с cmake парится нужно тебе. Спрашивается, зачем?

Для цмака тоже почти все эти тесты есть.

Спрашивается, зачем?

Во-первых - ради переносимости на Windows в том числе. Во-вторых - чтобы к m4 не прикасаться.

m4 - это плохо?

Чем же это m4 Вам так насолил?

Из cmake можно запустить configure с помощью custom_command. Я так некоторое время включал в свое дерево исходников libevent пока не написал для него CMakeLists.txt.

Это всё слишком сложные сценарии. Проще сразу нормальную систему сборки использовать чем потом так геморроиться.

> Во-вторых - чтобы к m4 не прикасаться.

Связку макроязык+shell заменили говно-DSL. Не то, чтобы это мега продвинутое решение, решающее какие-либо проблемы. Так, куча фантиков вроде цветного вывода по-дефолту.

Во-первых - ради переносимости на Windows в том числе.

Сюрприз - изобретать ещё один язык для этого не нужно. Можно писать на python, к примеру (google waf, scons). Так не объяснишь, в чём же скрытый смысл CMake и её киллер-фичи?

>А на сколько сложно такую штуку забомбить (я про конвертер)?

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

Связку макроязык+shell заменили говно-DSL.

Но это переносимый говно-DSL.

Сюрприз - изобретать ещё один язык для этого не нужно. Можно писать на python, к примеру (google waf, scons).

Можно было. Язык CMake действительно плохой, но waf или scons уже умеют настраивать сборку (поиск библиотек), и у них уже есть «искаропки» такое же количество модулей Find*?

Запустить из cmake скрипт ./configure можно. Можно что угодно запустить: execute_process(COMMAND «sh» "-c" «${CMAKE_CURRENT_SOURCE_DIR}/configure »)

Но если требуется перевести программу на cmake, то это не поможет: придётся полностью выпиливать autotools.

>Проще сразу нормальную систему сборки использовать чем потом так геморроиться.

Кто же спорит. Просто в мире полно ГГМнутых

> > Связку макроязык+shell заменили говно-DSL.

Но это переносимый говно-DSL.

m4 & shell то же очень переносимые. Python то же переносим. Вывод: CMake - в топку

> Сюрприз - изобретать ещё один язык для этого не нужно. Можно писать на python, к примеру (google waf, scons).

Можно было. Язык CMake действительно плохой, но waf или scons уже умеют настраивать сборку (поиск библиотек), и у них уже есть «искаропки» такое же количество модулей Find*?

Умеют. Если сравнивать количество существующих модулей для систем конфигурации/сборки - то тут однозначно выигрывают autotools. Вывод - по этому критерию CMake опять в ж#%е.

Если сравнивать гибкость и лёгкость использования языков/DSL - то python, или связка shell+стандартные утилиты (awk, ...) рвут на части велосипед от CMake. Вывод - CMake ничего не даёт

Так зачем же нужен этот CMake?

m4 & shell то же очень переносимые.

+ coreutils и получается, что для autotools надо половину MinGW поставить, вместо одного CMake. Autotools - в топку.

Python то же переносим. Вывод: CMake - в топку

В scons, waf есть набор модулей сопоставимый с CMake? Нет? CMake - не в топку.

Если сравнивать количество существующих модулей для систем конфигурации/сборки - то тут однозначно выигрывают autotools. Вывод - по этому критерию CMake опять в ж#%е.

Autotools уже научился с Visual Studio работать?

Если сравнивать гибкость и лёгкость использования языков/DSL - то python, или связка shell+стандартные утилиты (awk, ...) рвут на части велосипед от CMake. Вывод - CMake ничего не даёт

Вопрос о модулях для scons и waf остаётся, если их количество не сопоставимо с количеством модулей cmake, то python при всей его хорошести как языка программирования на роль системы не годится. У нормально написанных скриптов на cmake в зависимостях только cmake (что очевидно) и компилятор. У Autotools - bash, make, m4, coreutils, awk, и прочие программы типичные для *nix систем, но не для Windows.

> Autotools уже научился с Visual Studio работать?

Вы бы так и писали, что киллер фича CMake - это работа с виндовыми компиляторами и на чистом виндовом окружении без всего (только с компилятором), и ещё одна зависимость в виде python - не нужна.

«Killer feature cmake» — возможность быстро писать сборочные скрипты, которые работают быстро. autocrap с нуля будет програмку на 100 строк обрабатывать секунд 30. Не удивительно, что suckless.org и проекты-сателлиты вообще перешли на чистый make