Путь к KDE4: CMake — новая make-система для KDE4

Как он (автор СКонса) умудрился из двух довольно таки внятных и декларативных по сути и стилю прообразов, Makefile'ов и питоньих сорцов соорудить такое?.. BSD'шные портовые Makefile'ы и то декларативнее выглядят, несмотря на то, что BSD'шники таки не умеют пользоваться собственным make'ом, а легендарное качество BSD'шных портов воспето в эпосах и легендах :-) Да-да, я один д'Артаньян.

Хммм... я тут тоже недавно проект из одних исходников сопрягал с autotools... Справился за часа 4, учитывая полную незнакомость с предметом, с тихим матом и чтением документации. И работает ведь, и наличие фортрана почему-то не проверяет... =) Правда остались вопросы, но думаю дальнейшее курение доков поможет.

Но ваша ода cmake меня пленила =) пойду изучать предмет. Посмотрим на что оно способно.

> libtool к POSIX никакого отношения не имеет. Этот уровень придумали чтобы иметь побольше проблем со сборкой и использованием. Он намертво цепляет абсолютные пути до библиотек, вырубая не только возможность кросс-сборки, но и сборки в обособленном DEST.

Хе-хе, --mode=relink.

Зачем? А очень просто, на некоторых более других платформах (e.g. MacOSX) в собираемые бинарники пробиваются пути до прилинкованных библиотек. Поэтому, строго говоря, без этого этапа не обойтись при _корректной_ сборке, в том числе, и в билдруты (но, на самом деле, не только в них).

Ну и насчет того, что он вырубает намертво... Вы, мягко говоря, погорячились :-).

> BTW, если кто скажет, какую проблему autotools (ну, илм cmake) решают, какую я не могу решить в рамках GNU make, ... с меня пиво.

Да нет, прелесть гнутого тулчейна состоит, в том числе, в том, что на выходе у него - вполне себе настоящие статические GNUMakefile'ы. Так что, никто не мешает навалять эти мэйкфайлы руками, знаете, как это там... русская пословица о необычайных стайерских качествах нездорового животного.

Просто при написании этих Мэйкфайлов нужно обязательно держать в башке все эти странности всяких разных странных платформ... Только у меня там (в башке) с годами остается все меньше и меньше места, поэтому мне проще пользоваться гнутым тулчейном (ну и цмэйком, хотя внутри в цмэйка все заметно менее упорядочено).

>BTW, если кто скажет, какую проблему autotools (ну, илм cmake) решают, какую я не могу решить в рамках GNU make, ... с меня пиво.

Уменьшают порог входа для newbee, этого достаточно?

>Уменьшают порог входа для newbee, этого достаточно?

Уменьшают порог входа для "newbee" как раз новые модные cmake'и и scons'ы/waf'ы

> Зачем? А очень просто, на некоторых более других платформах (e.g. > MacOSX) в собираемые бинарники пробиваются пути до прилинкованных > библиотек.

Это feature от libtool (по другому оно не умеет). А оно там не надо.

> что на выходе у него - вполне себе настоящие статические > GNUMakefile'ы

Котрые редактировать не следует. Как это правильно было замечено. Только зачем было городить

Про 'изоляцию' от системы --- это тоже сказки. Пробовали сменить компилятор на отличный от gcc? Поддержка не-очень-распространенной платформы --- больше борьбы с autotools, чем собственно отражение особенностей.

Про несовместимость версий autotools тут уже упоминали.

Чтобы написать сборку чего-то оригинального, надо не только написать эту сборку, но и убить кучу времени чтобы уговорить m4 это сожрать как надо + попасть в зависимость от версии autotools...

> что на выходе у него - вполне себе настоящие статические > GNUMakefile'ы Которые редактировать не следует. Как это правильно было замечено. Только зачем было городить скрипт в 700K чтобы создать ЭТО?

(я уложился в 300K, и это работает на всех основных платформах и с 6 семействами компиляторов.)

>> BTW, если кто скажет, какую проблему autotools (ну, илм cmake) >> решают, какую я не могу решить в рамках GNU make, ... с меня пиво.

> Уменьшают порог входа для newbee, этого достаточно?

Для сборщика --- индифирентно, разницы нет. Для разработчика --- autotools увеличивают проблемы. И из какой категории этот newbee? Если разработчик --- то, как показывает опыт, кухарка, с уровнем знаний кухарки не может управлять государством.

Почитайте про make-систему waf - http://www.gnuplanet.ru/main/docs/devel/waf_build_system.php

>> К сожалению, оно не работает. На твоём Linux/Intel --- да, возможно, ты этого не заметишь. На любой другой платформе возникает масса проблем. Правда, CMake вообще функциональностью libtool не обладает, так что тоже в пролёте

> Ой, не лечите меня, пожалуйста. Я не скажу за все платформы, но на MacOSX / PPC с libtool-1.5 тоже все неплохо. С 1.4, да, есть известные проблемы.

Вот-вот. Ничего, кроме двух самых попсовых платформ не видел, а туда же... Или же применяешь libtool только для хелловордов, уж не знаю. К твоему сведению, 1.5 пользоваться невозможно вообще, количество ошибок в этой ветке libtool зашкаливает все разумные пределы. Мне ещё два года назад пришлось перейти на 2.0 (это до сих пор CVS), там многое исправлено, но тем не менее этот libtool тоже не подарок.

Любые компиляторы, отличные от GCC и платформы, отличные от Linux являются для libtool проблемой. В связи с этим возникают большие сомнения в необходимости использования этой псевдоавтоматизации.

> Просто при написании этих Мэйкфайлов нужно обязательно держать в башке все эти странности всяких разных странных платформ... Только у меня там (в башке) с годами остается все меньше и меньше места, поэтому мне проще пользоваться гнутым тулчейном (ну и цмэйком, хотя внутри в цмэйка все заметно менее упорядочено).

При использовании autotools тебе всё это нужно знать ничуть не меньше. autotools _якобы_ снимают с программиста все проблемы переносимости, а по факту всё равно приходится тестировать на каждой платформе отдельно и каждый раз решать все проблемы вручною (за исключением самых тривиальных, с которыми autotools действительно справляются).

> Это feature от libtool (по другому оно не умеет). А оно там не надо.

Что не надо? Пробивать пути до библиотек? Почитайте документацию на Mach-O, libtool тут, в общем, непричем.

>> что на выходе у него - вполне себе настоящие статические >> GNUMakefile'ы

> Котрые редактировать не следует. Как это правильно было замечено. Только зачем было городить

Их не следует редактировать, особенно неподготовленным людям. Но глядеть в них не возбраняется. Более того, иногда это полезно и необходимо. Кроме того, для отладки мэйкфайлов есть стандартные методики, предоставляемые мэйком, которые позволяют оттрейсить всю эту машинерию понять, почему исполняются те или иные цели итп.

По опыту могу сказать, что ковыряться, например, в системе портовых BSDMakefile'ов (там где вовсю галимая императивщина, .if'ы, .for'ы, .include'ы и прочие радости жизни), заметно менее удобно, нежели в один статический Мэйкфайл, выплюнутый automake'ом.

> Чтобы написать сборку чего-то оригинального, надо не только написать эту сборку, но и убить кучу времени чтобы уговорить m4 это сожрать как надо + попасть в зависимость от версии autotools...

Хе-хе, сдается мне, вы просто не умеете его готовить ;-). В случае с m4 главное - это осознать на подсознательном уровне, что это - _макроязык_ . "И это меняет все" (C) идиотская реклама Нескафе. По крайней мере, после осознания этого факта написание m4-макросов стало для меня совершенно ненапряжным.

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

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

И таки да, я знаю про некоторые ошибки :-). Но, чес-слово, в моём случае не смертельно.

> Хе-хе, сдается мне, вы просто не умеете его готовить ;-).

Я не про то что нельзя чего-то там сделать. Я (и, похоже, я не одинок в этом вопросе) про то, что эта система препятствует (затрудняет) решение некоторых, весьма характерных задач.

Вот скажите, какую задачу решает каждое средство в цепочке

autoconf -> automake -> configure -> make?

И потом посмотрим, направлено ли это действие на достижение основной цели. Не решается ли одна задача более одного раза?

Какую цель преследовали авторы libtool --- для меня вообще загадка. Наложить дополнительные ограничения на расположение библиотек, в придачу к Operational Environment и опциям линковщика? Перечислить библиотеки в куче вспомогатальных файлов? Мешать линкеру делать свою работу?

> Почитайте про make-систему waf - http://www.gnuplanet.ru/main/docs/devel/waf_build_system.php

Спасибо за ссылку.

Мне кажется, что SCons & fiends пытаются решить не свою задачу.

Что нужно от системы сборки?

1. Дать возможность описать граф вывода цели 2. Дать возможность описать действия, необходимые для перехода от одной вершины к другой 3. позволить делать 'обобщения' действий, м.б. параметризировать их (это можно сделать либо через 'функции' либо через 'макроподстановку') 4. предложить готовые подграфы вывода для характерных задач 5. не мешать замещать предложенные подграфы вывода (или их части) своими.

Что НЕ ДОЛЖНА делать подсистема сборки?

1. подменять package system 2. пытаться решить задачи linker/loader'а вместо него 3. формировать зависимости на основе своего parser'а.

IMO данным целям лучше всего удовлетворяют GNU make и BSD make. У них и семантика одинаковая. Различие только в синтаксисе.

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

Как только тебе придёт первый баг-рипорт на тему: "у меня Ваши динамически загружаемые библиотеки и бинарники не собираются VisualAge на AIX!" (или хотя бы GCC на Solaris 7), вот тогда ты сразу задумаешься, а накой чёрт в твоём проекте эти килобайты магического шелл-кода под названием autotools, если он не делает того, что от него требуется? Кстати, а для mingw и darwin математическую библиотеку по-прежнему вручную подключать надо, как и много лет назад?

И удар ниже пояса: а как с помощью autotools использовать компилятор Visual C++ на Windows?

> И таки да, я знаю про некоторые ошибки :-). Но, чес-слово, в моём случае не смертельно.

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

>>CMake не умеет кросс-компиляцию.

> Умеет

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

>>Поэтому сразу фтопку.

>вас туда же

...поэтому всё же фтопку.

>Это гентушнеги постоянно чегото ждут, а нормальные люди просто юзают. Сейчас и сегодня. Текущую стабильную версию. И при этом весьма комфортно себя чувствуют :)

Гентушникам ничего ждать не надо, у них всегда стоят самые свежие пакеты и все проги собраны с оптимизацией под конкретную систему, что обеспечивает максимальное быстродействие. =) Это кубунтоиды и прочие малолетки круглыми сутками сидят на ЛОРе и ждут когда кто-нибудь про генту заикнётся...

>Которую ни один вменяемый гентушнег не юзает... :) Небольшая поправка: большинство гентушников юзает отдельные пакеты из нестабильной ветки, которые либо слишком долго проверяются ( openoffice, kde), либо находится в полуэкспериментальном состоянии (initng, beryl). Если же кто-то размасирует _весь_ софт, то он может быть и гентушник, но точно невменяемый. ;)

P.S.: Сижу на стабильной ветке, из размаскированного только опера и openoffice, особых глюков не замечено... P.S.S.: Кстати, в генту уже давным-давно кде 3.5.5 перешёл в стабильную ветку... А глупый Sherak наверное ещё полгода будет ждать, пока эту версию в релиз его любимого дистра включат (в генту как-раз к этому времени уже 3.5.6 стабилизируется :))

>Хотя и это понятно - вечный девиз команды КДЕшников, "наш лисапед вперёд летит!".

>самокатчик, лети себе к стене, людей нормальных бредом не терзая

+10

К теме Вышел третий snapshot KDE 4 http://dot.kde.org/1172249109/ After "Krash", the first development snapshot, this is another milestone towards KDE 4.0 which will be released later this year. The KDE developers aim at a release in summer 2007. Странно, мне казалось, что не выпустят до конца года ...

> Кто-нибудь видел прогу на фортране? Я - нет )

тоже мне, нашла чем гордиться :)

> Вот скажите, какую задачу решает каждое средство в цепочке > autoconf -> automake -> configure -> make? И потом посмотрим, направлено ли это действие на достижение основной цели. Не решается ли одна задача более одного раза?

Я так понимаю, исходили авторы из следующих положений:

1. ендлузеру на своей машине не надо иметь ничего, кроме sh, make и собственно используемых средств сборки. 2. сам по себе make и статические Makefile'ы неплохи, к ним нужно только прилепить препроцессор для автоматизации часто используемых операций.

Итак, что получили.

1. autoconf. Запускается, по идее, только на машине девелопера и позволяет описывать требуемые конфигурационные и environmental тесты в виде типа удобных макросов. m4, наверное, не подарок, но, в общем, по большому счёту, какая разница, какой макроязык использовать. А в m4 еще и не побалуешь особо...

2. automake. Запускается, по идее, только на машине девелопера и является макроязыком для написания типичных сборочных [GNU] Makefile'ов. Слово "типичных" ключевое, хотя, конечно, некоторую свободу действий [потом] добавили.

3. configure. Запускается на машине собирающего и проводит эти самые "конфигурационные тесты". По идее, самодостаточен и заведомо заработает на любой POSIX-совместимой системе, хотя, конечно, наворотить в тестах можно чего угодно...

4. make. Сборка на основании подготовленных сорцов и результатов тестов.

Что из этих действий можно выбросить, как ненужное?

> Какую цель преследовали авторы libtool --- для меня вообще загадка. Наложить дополнительные ограничения на расположение библиотек, в придачу к Operational Environment и опциям линковщика? Перечислить библиотеки в куче вспомогатальных файлов? Мешать линкеру делать свою работу?

Авторы libtool преследовали цель, описанную, что удивительно, в info libtool: снять с девелопера нужду думать о том, _как_ собирать и линковать [динамические] бинарники. Не _что_ прилинковывать, а _как_ . И, судя по тем двум-трём самым попсовым платформам, на которых я использовал её для сборки библиотек, кое-что у них получилось. Хотя, конечно, повторю, пока оно работает, внутрь неё лучше не заглядывать.

Из всего этого зоопарка, пожалуй, только пара automake/libtool занимаются пересекающимися задачами. Но, видимо, в парадигме статического Makefile'а кое-кому оказалось проще вынести сборочно-линковочную логику на другой уровень, чем пытаться уложиться в универсальные сборочные правила для всех. Впрочем, как говорят наши товарищи со странных "непопсовых" платформ, все равно ничего не вышло :-).

Все ж таки, в какой ситуации у вас не получается воспользоваться libtool'ом для сборки/установки в указанный билдрут?

> Я так понимаю, исходили авторы из следующих положений:...

Вопрос ставился не "что оно делает", а "какую цель достигает", ну и какой ценой достигает.

Смотрите, что получается:

1. autoconf: цель --- вставить тексты проверок и детектирования в файлы внутри проекта. (интересно, зачем здесь их включать вместо того чтобы просто воспользоваться?) При этом, скрипты на shell с использованием awk, sed, etc. завернуты в макросы m4. Лишний уроень, который не дает ничего, окромя добавления сложности. Цель достаточно сомнительная сама по себе.

2. automake. создать makefiles в "сверхобобщенном" виде --- все макроопределения включены, использованы только кашерные конструкции make. Это было актуально лет 15 назад. Сейчас GNU make есть везде (дык, без него FSF tools невозможны); или кто использует autotools на *BSD? Цель не актуальна. В настоящее время только добавляет лишний уровень.

3. configure. цель --- определить состав системы всеми имеющимися в наличии скриптами. Чрезвычайно избыточная вещь, вносит ограничения, не накладываемые проектом. И, что, самое, интересное, необходимые 'ограничения' уже есть в самом проекте. Лишнее место для ограничений --- ведет к потенциальной несогласованности проекта и усложняет его maintenance.

4. make. Собственно сборка. Это не вычеркнуть. Цели 1..3 могут быть достигнуты на этом этапе.

> Авторы libtool преследовали цель, описанную, что удивительно, в info libtool: снять с девелопера нужду думать о том, _как_ собирать и линковать [динамические] бинарники.

Удивительно то, что в придачу к правилам linker/loader'а они добавили огромную массу своих правил игры и ограничений, которая перевешивает сокрытые знания о специфике платформ. Как результат --- добавлена масса ограничений, проистекающая из особенностей libtool, которые отсутствуют в линковке и загрузке. Т.е. достоинства libtool сомнительны, а недостатки очевидны. BTW, проблемы естественным образом решаются в п.4 выше. (ну, или зачем перед этим был autoconf c кучей m4 скриптов, если все равно фактически ту же задачу перекладывают на libtool?)

> 1. ендлузеру на своей машине не надо иметь ничего, кроме sh,

Уточним: в 99% случаев это должен быть не sh, а bash.

> make

Уточним: в 99% случаев это должен быть GNU make.

> и собственно используемых средств сборки.

...и ещё sed, awk, echo, и массу других вещей, непонятно как относящихся к задаче сборки проекта.

> autoconf. Запускается, по идее, только на машине девелопера и позволяет описывать требуемые конфигурационные и environmental тесты в виде типа удобных макросов. m4, наверное, не подарок, но, в общем, по большому счёту, какая разница, какой макроязык использовать. А в m4 еще и не побалуешь особо...

Невероятно негибкий язык, плюс масса недоделок в самих макросах. Отсутсвие макросов для множества распространённых задач. Как, скажем, стандартным макросом протестировать библиотеку на чистом C++? Её интерфейсы? А никак --- своё пишите.

> automake. Запускается, по идее, только на машине девелопера и является макроязыком для написания типичных сборочных [GNU] Makefile'ов. Слово "типичных" ключевое

Нет, ключевым является слово "C". automake предназначен для сборки программ на C. Любые другие языки не поддерживаются. При этом отсутствует возможность легкого расширения automake на другие языки, т.к. система немодульная.

> configure. Запускается на машине собирающего и проводит эти самые "конфигурационные тесты". По идее, самодостаточен и заведомо заработает на любой POSIX-совместимой системе

На любой системе он заработает только в том случае, если разработчик об этом специально позаботился и вычистил все bash'измы, gmake'измы и проч. На Windows вообще не заработает.

> Авторы libtool преследовали цель, описанную, что удивительно, в info libtool: снять с девелопера нужду думать о том, _как_ собирать и линковать [динамические] бинарники.

Эта цель провалилась, ибо авторы libtool оказались не в состоянии написать универсальный инструмент для всех платформ и всех компиляторов. Даже для избранного числа платформ они этого сделать не смогли. И поддерживать свой продукт в актуальном состоянии они тоже не способны. А ещё ответьте мне на следующий вопрос: если мы знаем всю информацию о системе, получив её после этапа тестов, то зачем нам вообще этот libtool?! Чтобы проект дольше компилировался?

> И, судя по тем двум-трём самым попсовым платформам, на которых я использовал её для сборки библиотек, кое-что у них получилось.

Фокус в том, что на этих 2-3 платформах ты спокойно можешь обойтись вообще без libtool! Вот что тебе мешает линковаться без него?

А ещё добавлю сюда, что использование autotools приводит к необходимости параллельно держать две-три дополнительные системы сборки: autotools для юниксов и мейкфайлы/проекты для MSVS (отдельно для обычного MSVS, отдельно --- для Embedded). Это --- автоматизация?! Нет уж, ну его нафиг. К счастью, есть SCons, CMake и замечательный Waf.

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

Я, собственно, уже ответил на этот вопрос. В предыдущем посте.

Ваше недоумение распадается на два вопроса:

1. зачем таскать тесты с собой

2. зачем нужен автоконф.

Повторяю: тесты с собой нужно таскать, чтобы человеку, собирающему софтину (ендлузеру), не требовалось ничего кроме того, что требуется непосредственно для проведения тестов и сборки.

Автоконф нужен для того, чтобы у _девелопера_ была возможность переиспользования этих тестов путем оформления их в виде макросов. Собственно говоря, и ЦМэйк, и СКонс в этой части ничего нового не выдумали. Те же макросы, только оформленные в своём синтаксисе, и лежащие внутри сборочной. Впрочем, в вафе тесты точно так же пакуются внутрь каждого проекта, опять таки, для того, чтобы уменьшить список софта, необходимого для того, чтобы провести сборку.

Да, наверное, m4 - не самый элегантный из макроязыков. Но, по-моему, пофиг.

> 2. automake. создать makefiles в "сверхобобщенном" виде --- все макроопределения включены, использованы только кашерные конструкции make. Это было актуально лет 15 назад. Сейчас GNU make есть везде (дык, без него FSF tools невозможны); или кто использует autotools на *BSD? Цель не актуальна. В настоящее время только добавляет лишний уровень.

Не в "сверхобобщенном виде". А в виде часто используемых шаблонов. К тому же, вы по желанию части этих шаблонов (цели, переменные) можете перекрыть, и автомэйк это поймет. Другое дело, что нет штатной возможности определить свои шаблоны. И в этом - огромный недостаток автомэйка.

Ну и насчет того, что GNU make не используется при сборке на BSD. Еще как используется, но только не в "core system".

> 3. configure. цель --- определить состав системы всеми имеющимися в наличии скриптами. Чрезвычайно избыточная вещь, вносит ограничения, не накладываемые проектом.

Я, честно говоря, не понял... Если вас по каким-то причинам не устраивает выхлоп автоконфа, вам ничего не мешает написать скрипт configure руками. Некоторые проекты, в особенности, возглавляемые матерыми хаксорами (н-р, MPlayer) пошли именно по такому пути, дескать, пересобирать долго (ну, о том, что автоконфовый ./configure неплохо умеет пользоваться кэшем, матерые хаксоры, видимо, не прочли). Схема сборки от этого если и поменялась, то не сильно, разве что некоторые стандартные возможности, типа сборки в вынесенном каталоге, были утрачены.

> 4. make. Собственно сборка. Это не вычеркнуть. Цели 1..3 могут быть достигнуты на этом этапе.

Хех... Могут. Но результат оказывается... не того...

1. Результаты тестов лучше иметь до сборки как таковой, не правда ли? То есть, конфигурационные цели должны отработать до все остальных, не так ли?

2. Должна существовать возможность сайт-вайд конфигураций и использования [редактируемых] кэшей.

3. Наконец, подчас полезно иметь возможность сборки не в дереве исходников, что-то типа такого:

cd mysoftware-1.0
rm -rf build
mkdir build
cd build
../configure ...
make

> Удивительно то, что в придачу к правилам linker/loader'а они добавили огромную массу своих правил игры и ограничений, которая перевешивает сокрытые знания о специфике платформ. Как результат --- добавлена масса ограничений, проистекающая из особенностей libtool, которые отсутствуют в линковке и загрузке...

Я, честно говоря, не пойму, о чем вы. Сказано много, а конкретных примеров - нет.

> Уточним: в 99% случаев это должен быть не sh, а bash.

А это уже к авторам тестов, ага? В доке на автоконф специальная глава посвящена тому, как правильно писать тесты. И таки нет, не соглашусь. Если я правильно помню, то уже даже в дебиан /bin/sh - это таки dash, который, конечно, хоть и POSIX shell, но _очень_ покоцанный. Тем не менее, программы собираются.

> Уточним: в 99% случаев это должен быть GNU make.

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

> Невероятно негибкий язык, плюс масса недоделок в самих макросах. Отсутсвие макросов для множества распространённых задач. Как, скажем, стандартным макросом протестировать библиотеку на чистом C++? Её интерфейсы? А никак --- своё пишите.

Дяденька, ну, вы это уже, отделяйте тех, кто производит цемент от тех, кто кладет стену.

Гибкость _макро_-языку не нужна. Вообще. Макроязыку нужно чёткое и предсказуемое поведение и корректная замена макроподстановок. Кто не допёр, рассказываю ещё раз: m4 - макроязык. Его задача - каждое вхождение одной последовательности символов заменить на другую последовательность символов. Все.

Что касается C++, то опишите задачу. Кстати говоря, для autoconf существует неплохая библиотека сторонних макросов для разных нужд. Если опишете задачу и расскажете, как её решать (на уровне C++ кода), можно будет пихнуть решение туда. Если его там еще нет.

> Нет, ключевым является слово "C". automake предназначен для сборки программ на C. Любые другие языки не поддерживаются. При этом отсутствует возможность легкого расширения automake на другие языки, т.к. система немодульная.

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

> На любой системе он заработает только в том случае, если разработчик об этом специально позаботился и вычистил все bash'измы, gmake'измы и проч. На Windows вообще не заработает.

Никогда не говори никогда. Я, опять-таки, уже говорил магическое слово: mingw. Вполне себе в виндовсе работает ;-). Причём, я _проверял_ действительно работает, и ACE/TAO там собирал, и неслабые проекты на нём (да-да, с черезжопным преодолением ограничений двухстадийной сборки, когда нужно было стабы из .idl'ей генерить). И, что характерно, сборка на линуксе ничем не отличалась от сборки на винде. И, с высоты нынешнего опыта могу сказать, что и на макоси бы завелось.

> Фокус в том, что на этих 2-3 платформах ты спокойно можешь обойтись вообще без libtool! Вот что тебе мешает линковаться без него?

Все-таки ELF, PE и Mach-O сильно разные с точки зрения организации библиотек и динамически загружаемых модулей. Поэтому я предпочитаю иметь прокладку между мной и линкером. Не знаю, кому как, но _мне_ так проще, и целей своих я добиваюсь.

> Нет уж, ну его нафиг. К счастью, есть SCons, CMake и замечательный Waf.

Ну, я уже говорил, что я предпочитаю иметь возможность видеть глазами тот мэйкфайл, который сгенерится на выходе (например, BSD ports mk не нравятся мне как раз тем, что вся мегалогика остается где-то в мозгах мэйка, а не на диске). SCons к тому же приводит к довольно уродливой с моей точки зрения императивщине, как только дело касается чего-нибудь не слишком тривиального. У ЦМэйка было плоховасто с документацией, ну и некоторые его недостатки я отметил выше по треду. Ну и наконец все три системы очень юны. Говорить о том, что они хороши я смогу только тогда, когда _много_ разных независимых проектов начнут ими пользоваться, и количество обрабатываемых задач будет реально сравнимо с автотулзовым. А пока это все похоже на декларацию о намерениях от тех, кому претит m4 и admin/am_edit.

Autmake, autoconf и libtool - очень кривые системы. Несовместимость версий, птичий язык m4, необходимость разбираться и в макросах m4 и в синтаксисе .in / .am -- все это autotools.

Я так и не смог сделать на их основе сборку плагинов (.so, загружаемых через dlopen). Забавно, что это не смогли сделать и другие разработчики (apache, php и т.д.).

В cmake же мне было достаточно написать ровно три строчки: указать список файлов для сборки .so, тип сборки плагина и имя получаемого .so. Причем, все это с полпинка завелось и под Linux и под FreeBSD и даже под Solaris 10 с кучей разных компиляторов.

>У ЦМэйка было плоховасто с документацией,

Сейчас документации и информации в списках рассылки и на сайте столько, что почти любой вопрос решается безо всяких проблем.

Безусловно, cmake тоже неидеален. Но уж во всяком случае - лучше чем autotools. Возможно, кому-то и нужны autotools, но я свой выбор сделал: cmake.

To anonymous (*) (25.02.2007 17:29:30)

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

> ... Как, скажем, стандартным макросом протестировать библиотеку на чистом C++? Её интерфейсы? А никак --- своё пишите.

Я надеюсь, Вы не имеете в виду, что система сборки должна обеспечивать тестирование. :-)

> К счастью, есть SCons, CMake и замечательный Waf.

Мне вот в SCons не понавилось то, что они используют свой parser для формирования dependencies. Это чревато проблемами.

С моей точки зренеия, система сборки должна предоставить

- способ построения графа вывода цели (целей) - функции с параметрами или макрооопределения для метаописания действий (переход из одной вершины графа вывода в другую) - достаточно богатый набор для обработки строк - м.б. функции для работы с файлами (это полезно для Wins)

Обладая этим набором, можно построить хорошую систему сборки.

> Повторяю: тесты с собой нужно таскать, чтобы человеку, собирающему софтину (ендлузеру), не требовалось ничего кроме того, что требуется непосредственно для проведения тестов и сборки.

Make?

> Если вас по каким-то причинам не устраивает выхлоп автоконфа, вам ничего не мешает написать скрипт configure руками.

Не устраивает. Поэтому autotools и не пользуюсь. В своих проектах.

> 1. Результаты тестов лучше иметь до сборки как таковой, не правда ли? То есть, конфигурационные цели должны отработать до все остальных, не так ли?

Неправда. Не так. Пример --- туча тестов на работоспобность executable. При cross-compilation они в принципе не могут быть выполнены. А стоят.

Затем: зависимости появились как в тестах, так и в собственно кодах проекта. Т.е. зависимости (вообще говоря, несвязанные) появились в двух местах. Т.е. эизненный цикл их совершенно различный (проблемы в разработке и сопровождении). Однако эти тесты даже не являются необходимыми: ошибки при сборке все покажут. Т.е. предварительные тесты не являются ни необходимыми, ни достататочными. А воспрепятствовать (введя ложные ограничения) вполне могут и делают это.

> Я, честно говоря, не пойму, о чем вы. Сказано много, а конкретных примеров - нет.

Ну, тут извилины надо напрячь. Или попробовать выйти за пределы двух "попсовых" сборок. Например --- собрать с SUNSoft's cc вместо gcc. Или заменить libstdc++ на STLport при сборке C++.

> Я так и не смог сделать на их основе сборку плагинов (.so, загружаемых через dlopen). Забавно, что это не смогли сделать и другие разработчики (apache, php и т.д.).

Пожимая плечами: а кадеешнеги смогли :-). Причем, в общем, там не так много надо ;-).

> > Повторяю: тесты с собой нужно таскать, чтобы человеку, собирающему софтину (ендлузеру), не требовалось ничего кроме того, что требуется непосредственно для проведения тестов и сборки.

> Make?

Писать тесты на мэйке, я вас уверяю - это ни с чем не сравнимое удовольствие. BSD ports тому примером.

>> 1. Результаты тестов лучше иметь до сборки как таковой, не правда ли? То есть, конфигурационные цели должны отработать до все остальных, не так ли?

> Неправда. Не так. Пример --- туча тестов на работоспобность executable. При cross-compilation они в принципе не могут быть выполнены. А стоят.

Стоят - уберите, есть способы. К тому же, я проглядел стандартную configure, тест на запускаемость там ровно один:

# Check the compiler produces executables we can run. If not, either # the compiler is broken, or we cross compile.

> Однако эти тесты даже не являются необходимыми: ошибки при сборке все покажут.

Вот здрасьте. Ошибки при сборке:

1. Сложнее диагностировать (не найден какой-нибудь мелкий .h-файл, после чего тридцать пять страниц ошибок компиляции, связанных с неопределёнными типами).

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

3. Имеется чисто техническая проблема с мэйком. В нем нет готовых механизмов для ветвлений. Типа, шли-шли по одному пути, обнаружили, предположим, что у нас недостаточно библиотек установлено в системе, и переключились на bundled версии. Эти ветвления, конечно, можно организовать, в конце концов и синтаксис мэйка можно расширить, но только в итоге получится BSD ports: лапша пополам с солянкой из целей, условий и файловых флагов, к тому же, с очень слабым коэффициентом переиспользуемости кода различных тестов.

> Т.е. предварительные тесты не являются ни необходимыми, ни достататочными.

Если они являются недостаточными, разработчик - сам себе злобный буратина. Насчет необходимости, я, повторю сказанное выше: по-моему, лучше если ломается ./configure, чем когда ломается make. А время выполнения ./configure на проектах, хоть немного переросших GNU Hello, несравнимо меньше времени компиляции, особенно, по-настоящему плюсового кода. Что характерно, не я один так думаю, авторы CMake'а и прочих waf'ов со мной солидарны ;-).

>> Я, честно говоря, не пойму, о чем вы. Сказано много, а конкретных примеров - нет.

> Ну, тут извилины надо напрячь. Или попробовать выйти за пределы двух "попсовых" сборок.

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

> Например --- собрать с SUNSoft's cc

У меня сейчас нет соляриса под руками.

> Или заменить libstdc++ на STLport при сборке C++.

Вы поверите, что именно эту задачу я уже решал? Никакая ни rocket science, даже изгаляться как кадеешнегам не пришлось.

> > Неправда. Не так. Пример --- туча тестов на работоспобность executable. При cross-compilation они в принципе не могут быть выполнены. А стоят. > Стоят - уберите, есть способы. К тому же, я проглядел стандартную configure, тест на запускаемость там ровно один:

Edit 700K-script? Thanks a lot! 'я проглядел стандартную configure' --- стандартную какой версии?? Там семь пятниц на неделе, новые версии выходят раз в два месяца в среднем, и все со своими особенностями.

> Вот здрасьте. Ошибки при сборке: > 1. Сложнее диагностировать (не найден какой-нибудь мелкий .h-файл, > после чего тридцать пять страниц ошибок компиляции, связанных с неопределёнными типами).

Угу. Первая строка которого 'can't include file blah-blah.h'. Конечно очень запутанно и непонятно. А вот configure's 'boost not found', после большого ковыряния в log'ах (3шт., ответ во последней четверти 2M файла), оказываются попыткой запустить executable, собранный cross'ом.

> 2. Сложнее в поддержке, ендлузер вынужден весь выхлоп от мэйка упаковывать и отсылать разработчику. Причем, видимо, с задранным уровнем отладки, потому обычного выхлопа не всегда достаточно.

Бред. Негативный результат от configure проинтерпретировать и понять источник проблемы на порядок сложнее, чем от компилятора. Плюс к этому --- положительный результат configure не гарантирует успеха компиляции. Т.е. работать с первоисточником --- проще, приятнее и эффективнее. А не разбирать --- чьё это: ошибка писателя теста, писателя configure или автора целевых источников.

> > Т.е. предварительные тесты не являются ни необходимыми, ни достататочными. > Если они являются недостаточными, разработчик - сам себе злобный буратина

Очччень интересно. А что оно может предварительно протестировать? А ему откуда известно что мне надо? Заголовок? Какой заголовок? Версию .so? А что, со след. (пред.) версией не будет работать? ...

Пост-тесты (aka UT) --- понятно, тестируется функциональность моего проекта (и тесты я формирую исходя из своих соображений). Пред-тесты --- непонятно. Что тестируем-то?

> > Или заменить libstdc++ на STLport при сборке C++. > Вы поверите, что именно эту задачу я уже решал? Никакая ни rocket science, даже изгаляться как кадеешнегам не пришлось.

Покажите строчку линковки --- ибо применительно к autotools --- НЕ ВЕРЮ (ну, или ldd на результат).

но хоть с тем что autotools черезмерно усложнен и требует рефакторинга вы согласитесь?

Вообще судя по всему шило на мыло. Бейсикоподобный язык + весьма тяжело читающийся файл с правилами (если более-менее большой проект). В общем может быть лучше чем autotools но все-равно далеко еще не то...

>> Я так и не смог сделать на их основе сборку плагинов (.so, загружаемых через dlopen). Забавно, что это не смогли сделать и другие разработчики (apache, php и т.д.).

>Пожимая плечами: а кадеешнеги смогли :-). Причем, в общем, там не так много надо ;-).

Кадеешниги переехали на cmake. Так что это, скорее, показатель того, что проще сменить систему сборки чем жить дальше на autotools.

>> Уточним: в 99% случаев это должен быть не sh, а bash.

> А это уже к авторам тестов, ага? В доке на автоконф специальная глава посвящена тому, как правильно писать тесты.

Вот именно! Надо забить себе голову тонной совершенно бесполезной информации о переносимости скриптов, awk'ов, sed'ов и прочего, только ради того, чтобы решить задачу переносимой сборки! Я хочу написать переносимую программу на C, зачем мне знать что-либо об особенностях shell? Система сборки должна исключать shell вообще. Язык этой системы должен быть однозначным и переносимым сам по себе.

>> Уточним: в 99% случаев это должен быть GNU make.

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

Это до тех пор, пока мы не начали писать свои правила. А если начали, то смотри выше, та же ситуация, что и с шеллом.

>> Невероятно негибкий язык, плюс масса недоделок в самих макросах. Отсутсвие макросов для множества распространённых задач. Как, скажем, стандартным макросом протестировать библиотеку на чистом C++? Её интерфейсы? А никак --- своё пишите.

> Дяденька, ну, вы это уже, отделяйте тех, кто производит цемент от тех, кто кладет стену.

Написать такие макросы --- задача нетривиальная, для очень многих --- и непосильная. Напомню: макрос должен быть переносим. А ещё я заглянул в раздел "История autoconf" в мануале и выяснил, что он ведёт своё летоисчисление с 1991-го года. И до сих пор нет стандартного макроса для вышеописанной задачи! А ещё тут вспоминали про поиск скриптом компилятора Фортрана. Это делает макрос AC_PROG_LIBTOOL, и это поведение было таки исправлено в ветке 2.0, которая года три сидит в CVS и пока совершенно непонятно, когда она оттуда вылезет. Вопрос: почему очевидная вещь не была сделана с самого начала? Стоит ли доверять столь медленно и нестабильно развиваемому инструменту?

> Гибкость _макро_-языку не нужна. Вообще.

Макроязык не нужен. Вообще. Нужен нормальный человеческий язык, типа Питона, на котором можно было бы писать свои тесты и свою логику, а не смесь m4 с убогим шеллом. На то, что есть сейчас без смеха смотреть невозможно. Например, читаем описание главного макроса AC_INIT:

It is preferable that the arguments of `AC_INIT' be static, i.e., there should not be any shell computation, but they can be computed by M4.

Т.е. вот так уже не сделать:

MAJOR_VERSION=1 MINOR_VERSION=2 MICRO_VERSION=3 AC_INIT([My prog], $MAJOR_VERSION.$MINOR_VERSION.$MICRO_VERSION, [myprog@myprog.com], myprog)

Таких примеров куча. Нет уж, не нужен мне такой язык.

> Кстати говоря, для autoconf существует неплохая библиотека сторонних макросов для разных нужд.

Это autoconf-archive? Да уж, половина макросов оттуда устарела и неработоспособна, а более-менее работоспосбны только те, которые включаются в поставку autoconf'а.

> Ну, нет, не соглашусь насчет "С". Если переформулировать как "программы с двухстадийной сборкой" - то да, вы правы.

Нет, практически это только C. Yacc'и не считаются. А кто сейчас пишет проекты только на одном языке? Никто. Любой мало-мальски сложный проект содержит модули на 2-3 языках минимум.

>> На любой системе он заработает только в том случае, если разработчик об этом специально позаботился и вычистил все bash'измы, gmake'измы и проч. На Windows вообще не заработает.

> Никогда не говори никогда. Я, опять-таки, уже говорил магическое слово: mingw.

Mingw даже не рассматривается. Проект собирает из исходного кода заказчик. Он, что, должен будет выкачать mingw, поплясать вокруг него с бубном (и не надо спорить: плясать придётся, проверено), и только потом компилировать наш проект? Да ещё и компилятором gcc? И на всех сборочных системах так? А как ему интегрировать наш проект со своим (допустим, мы пишем middleware)? Как он в своём Visual Studio будет отлаживаться?

>> Фокус в том, что на этих 2-3 платформах ты спокойно можешь обойтись вообще без libtool! Вот что тебе мешает линковаться без него?

> Все-таки ELF, PE и Mach-O сильно разные с точки зрения организации библиотек и динамически загружаемых модулей. Поэтому я предпочитаю иметь прокладку между мной и линкером. Не знаю, кому как, но _мне_ так проще, и целей своих я добиваюсь.

Представь такую ситуацию: заказчик звонит и говорит: "У меня на системе Superix компилятором MegaC ваш проект некампелицца!" Ты получаешь аккаунт на систему, смотришь, что не работает и как оно должно быть, исправляешь параметры сборки --- вуаля! всё работает. Добавили новое правило, забыли о проблеме. Это в случае, если ты сам сборкой управляешь. Теперь рассмотриv вариант libtool: долго и нудно ищем, что же там не так в этих 200 КБ ужасного шелл-кода, находим ошибку, правим локальный libtool, поддерживаем свою версию libtool для всех своих проектов, отсылаем патч разработчикам, они обещают включить его в версию 2.0, которая выйдет через 20 лет, а до того момента держим свой libtool, да ещё и говорим заказчику, чтобы он ни в коем случае не запускал autogen.sh, чтобы наш правильный libtool не заменить на системный... ОНО НАДО?!

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

А что, в мейкфайлах заключена вся истина этого мира? SCons заменяет make. Смотри правила SCons. Какая разница?

> Так, в осознании проблем autotools мы с Вами, похоже, солидарны.

>> ... Как, скажем, стандартным макросом протестировать библиотеку на чистом C++? Её интерфейсы? А никак --- своё пишите.

> Я надеюсь, Вы не имеете в виду, что система сборки должна обеспечивать тестирование. :-)

Солидарны, но я целиком и полностью "за" наличие подсистемы конфигурирования как компонента единой системы конфигурирование-сборка. В autotools'ах это не так: как Вы правильно заметили, функциональность компонентов перекрывается, да и реализация никуда не годится.

> Представь такую ситуацию: заказчик звонит и говорит: "У меня на системе Superix компилятором MegaC ваш проект некампелицца!" > Ты получаешь аккаунт на систему, смотришь, что не работает и как оно должно быть, исправляешь параметры сборки --- вуаля! всё работает. > Добавили новое правило, забыли о проблеме. > Это в случае, если ты сам сборкой управляешь. > Теперь рассмотриv вариант libtool: долго и нудно ищем, что же там не так в этих 200 КБ ужасного шелл-кода, находим ошибку, правим локальный libtool, > поддерживаем свою версию libtool для всех своих проектов, отсылаем патч разработчикам, они обещают включить его в версию 2.0, которая выйдет через 20 лет, а до того момента держим свой libtool, > да ещё и говорим заказчику, чтобы он ни в коем случае не запускал autogen.sh, чтобы наш правильный libtool не заменить на системный... > ОНО НАДО?!

Именно, именно. И это ещё лёгкий вариант описан. А то ещё упрямо цепляется libqqq из /usr/lib/libfoo.la и портит всю малину. А убрать нельзя --- от этой /usr/lib/libfoo.la SuperProject заказчика зависит... А порядок просмотра библиотек libtool самостоятельно определяет. Ну и т.д. и т.п.

> Покажите строчку линковки --- ибо применительно к autotools --- НЕ ВЕРЮ (ну, или ldd на результат).

Просто капец какой-то... Станиславский на мою голову...

Итого:

alex@lythos tmp/c++/autot++ $ cat main.cc
#include <iostream>

int main(void)
{
std::cout << "Hello, world!" << std::endl;
return 0;
}
alex@lythos tmp/c++/autot++ $ cat configure.ac
# -*- Autoconf -*-
# Process this file with autoconf to produce a configure script.

AC_PREREQ(2.59)
AC_INIT(TestCXXProject, 1.0.0)
AM_INIT_AUTOMAKE
AC_CONFIG_SRCDIR([main.cc])
AC_CONFIG_HEADER([config.h])
AC_CONFIG_FILES([Makefile])

# Checks for programs.
AC_PROG_CXX

# Checks for libraries.

# Checks for header files.

# Checks for typedefs, structures, and compiler characteristics.

# Checks for library functions.
AC_OUTPUT
alex@lythos tmp/c++/autot++ $ cat Makefile.am
bin_PROGRAMS = cxxtest

cxxtest_SOURCES = main.cc
AM_CXXFLAGS = -pthread
AM_CPPFLAGS = -I/usr/include/stlport
cxxtest_LDADD = -lstlport

alex@lythos tmp/c++/autot++ $ make clean; make
test -z "cxxtest" || rm -f cxxtest
rm -f *.o
make all-am
make[1]: Entering directory `/home/alex/tmp/c++/autot++'
if g++ -DHAVE_CONFIG_H -I. -I. -I. -I/usr/include/stlport -pthread -g -O2 -MT main.o -MD -MP -MF ".deps/main.Tpo" -c -o main.o main.cc; \
then mv -f ".deps/main.Tpo" ".deps/main.Po"; else rm -f ".deps/main.Tpo"; exit 1; fi
g++ -pthread -g -O2 -o cxxtest main.o -lstlport
make[1]: Leaving directory `/home/alex/tmp/c++/autot++'
alex@lythos tmp/c++/autot++ $ ldd cxxtest
linux-gate.so.1 => (0xffffe000)
libstlport.so.5.0 => /usr/lib/libstlport.so.5.0 (0xb7e7f000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7e74000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb7e5f000)
libc.so.6 => /lib/libc.so.6 (0xb7d3f000)
libm.so.6 => /lib/libm.so.6 (0xb7d1a000)
/lib/ld-linux.so.2 (0x80000000)
alex@lythos tmp/c++/autot++ $ _

Аналогично для библиотек, собранных libtool'ом. В крайнем случае, может понадобится -nostdlib/-nodefaultlibs с подсовыванием crt*.o и прочей потребной случаю машинерии, которая, на самом деле, будет одинакова, что пользовались вы autotools'ами, что не пользовались.

Что-то, честно говоря, после таких выкриков "НЕ ВЕРЮ" не очень хочется обсуждать с вами что-либо по данной теме. Мне кажется, вы просто не знакомы с предметом.

P.S. Да, желающим повторить подвиг разведчика: не забудьте, что наличие autoscan и autoheader сильно упрощают жизнь.

> но хоть с тем что autotools черезмерно усложнен и требует рефакторинга вы согласитесь?

Просмотрите выше по треду, я отмечал явные недостатки, н-р, automake. Вопрос, на самом деле, в том, _как_ рефакторить. Пример ЦМэйка и СКонса меня не впечатлил.

Ой... Ну, блин, сеанс одновременной игры какой-то... E2-E4... Посмотрите, наконец, в <a_kde_program>/admin/am_edit. Подумайте, в каких именно случаях без этого шага не обойтись. И перечитайте, уж, сделайте одолжение, о чем я писал выше по поводу двух- и более- стадийной сборке.

Замечание для ценителей точности и начинающих:

Некоторые флаги я захардкодил прямо в Makefile.am. Для действительно переносимой сборочной среды неплохо в configure.ac вставить проверки на расположение заголовочных файлов STLPort'а и соответствующей библиотеки, ну и про корректную проверку на флаги многопоточности не забыть. Примеры того, как это делать, есть в документации и различных архивах макросов, например, вот здесь: http://autoconf-archive.cryp.to/acx_pthread.html

Умозрительный пример про Суперикс пропущен. Мне везло, у меня работает.

> А что, в мейкфайлах заключена вся истина этого мира? SCons заменяет make. Смотри правила SCons. Какая разница?

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

Кому Вы парите мозги, Козюльский?

> g++ -pthread -g -O2 -o cxxtest main.o -lstlport make[1]: Leaving directory `/home/alex/tmp/c++/autot++' alex@lythos tmp/c++/autot++ $ ldd cxxtest linux-gate.so.1 => (0xffffe000) libstlport.so.5.0 => /usr/lib/libstlport.so.5.0 (0xb7e7f000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7e74000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7e5f000) libc.so.6 => /lib/libc.so.6 (0xb7d3f000) libm.so.6 => /lib/libm.so.6 (0xb7d1a000) /lib/ld-linux.so.2 (0x80000000)

Строка `g++ -pthread -g -O2 -o cxxtest main.o -lstlport` НЕ МОЖЕТ НЕ ДАТЬ зависимость libstdc++.so.6 => /usr/lib/libstdc++.so.6 И её статической тоже быть не должно --- libgcc_s.so.1 специфично для сборки с динамической libstdc++. А вот -nostdlib обяжет еще startup/finit .o's добавить. Я должен после этого верить?

> Умозрительный пример про Суперикс пропущен. Мне везло, у меня работает.

Этот пример не умозрительный, а наоборот, один из наиболее частых при разработке _переносимого_ ПО, распространяемого в исходниках.

А почему ты игнорируешь всё вышеизложенное, что касается Windows? Как всё-таки быть с параллельной системой сборки? Я хочу иметь единую систему для любого окружения!

> Мне не нравится конкретная реализация СКонса и его правил. Слишком много императивности и маловато декларативности. К тому же, по части легкости принятия патчей в СКонс, хе-хе... Почитайте, как кадеешнеги метались между сборочными системами...

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

А то, что эти системы моложе autotools'ов ровным счётом ни о чём не говорит. Вон, autoconf'у 16 лет в обед, а вопросов к нему вагон. Толку-то с его возраста?

> Строка `g++ -pthread -g -O2 -o cxxtest main.o -lstlport` НЕ МОЖЕТ НЕ ДАТЬ зависимость libstdc++.so.6 => /usr/lib/libstdc++.so.6 И её статической тоже быть не должно --- libgcc_s.so.1 специфично для сборки с динамической libstdc++. А вот -nostdlib обяжет еще startup/finit .o's добавить. Я должен после этого верить?

(Пожимая плечами) мы не в храме, чтобы верить.

alex@lythos tmp/c++/autot++ $ g++ -v
Using built-in specs.
Target: i586-alt-linux
Configured with: ../configure --host=i586-alt-linux --build=i586-alt-linux --target=i586-alt-linux --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var/lib --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --disable-dependency-tracking --without-included-gettext --program-suffix=-4.1 --with-slibdir=/lib --enable-shared --enable-__cxa_atexit --enable-threads=posix --enable-checking=release --with-system-zlib --without-included-gettext --disable-multilib --enable-languages=c,c++,fortran,objc,obj-c++,treelang,java,ada --enable-java-awt=gtk --disable-plugin --with-native-libdir=/usr/lib/gcj-4.1 --enable-libgcj-multifile --with-cpu=i586 --with-arch=i586 --with-tune=pentium4
Thread model: posix
gcc version 4.1.1 20061011 (ALT Linux, build 4.1.1-alt10)
alex@lythos tmp/c++/autot++ $ rpm -qf /usr/bin/ldd
glibc-utils-2.5-alt3
alex@lythos tmp/c++/autot++ $ _

Проверяйте.

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

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

Метались они по одной простой причине. Им что-то там не понравилось, они кинулись было по своей привычке это улучшать, и получили, мягко говоря, неприветливое отношение автора к своим патчам. В итоге, форкнули SCons (в виде waf'а) и уползли на CMake.

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

> А почему ты игнорируешь всё вышеизложенное, что касается Windows?

У меня есть опыт только лишь поддержки проекта одновременно под юниксами (линуксом, в частности) и мингв. Работало. Я понимаю, что это не вполне честно, но, признаюсь, мой опыт использования msvc крайне незначительный.

> alex@lythos tmp/c++/autot++ $ g++ -v

> Using built-in specs.

> ...

> Проверяйте.

Это как раз подтверждение неудовлетворительности autotools; видимо, это было достигнуто следующим образом:

бойцы Alt-Linux'а прописали libstlport отдельным правилом в specs-file'е gcc (see 'gcc -dumpspecs'). Видимо, это оказалось самым разумным компромиссом в их неравной борьбе с autotools. Хотя... скорее, это правка внутри gcc/cp/g++spec.c, что еще веселее.

Какой вы нудный, право слово. Вот, слегка подкорректированный пример, с учётом сказанного выше про корректность теста на pthreads (так и так надо было причесывать проверку). Специально проверил не только у себя на альте, но и на убунте610

Итого:

builder@bubt610:~/autot++$ cat configure.ac
# -*- Autoconf -*-
# Process this file with autoconf to produce a configure script.

AC_PREREQ(2.59)
AC_INIT(TestCXXProject, 1.0.0)
AM_INIT_AUTOMAKE
AC_CONFIG_SRCDIR([main.cc])
AC_CONFIG_HEADER([config.h])
AC_CONFIG_FILES([Makefile])

# Checks for programs.
AC_PROG_CXX
AC_PROG_LIBTOOL

# Checks for libraries.
ACX_PTHREAD

# Checks for header files.

# Checks for typedefs, structures, and compiler characteristics.

# Checks for library functions.
AC_OUTPUT
builder@bubt610:~/autot++$ cat Makefile.am
bin_PROGRAMS = cxxtest

cxxtest_SOURCES = main.cc
#cxxtest_CXXFLAGS = -nostdinc++
AM_CXXFLAGS = $(PTHREAD_CFLAGS)
AM_CPPFLAGS = -I/usr/include/stlport
cxxtest_LDADD = -lstlport libtest.la $(PTHREAD_LIBS)

CXXLD = $(PTHREAD_CC)

noinst_LTLIBRARIES = libtest.la
libtest_la_SOURCES = lib.cc

builder@bubt610:~/autot++$ make clean; make
rm -f cxxtest cxxtest
rm -rf .libs _libs
test -z "libtest.la" || rm -f libtest.la
rm -f "./so_locations"
rm -f *.o
rm -f *.lo
make all-am
make[1]: Entering directory `/home/builder/autot++'
if /bin/bash ./libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I. -I/usr/include/stlport -pthread -g -O2 -MT lib.lo -MD -MP -MF ".deps/lib.Tpo" -c -o lib.lo lib.cc; \
then mv -f ".deps/lib.Tpo" ".deps/lib.Plo"; else rm -f ".deps/lib.Tpo"; exit 1; fi
mkdir .libs
g++ -DHAVE_CONFIG_H -I. -I. -I. -I/usr/include/stlport -pthread -g -O2 -MT lib.lo -MD -MP -MF .deps/lib.Tpo -c lib.cc -fPIC -DPIC -o .libs/lib.o
g++ -DHAVE_CONFIG_H -I. -I. -I. -I/usr/include/stlport -pthread -g -O2 -MT lib.lo -MD -MP -MF .deps/lib.Tpo -c lib.cc -o lib.o >/dev/null 2>&1
/bin/bash ./libtool --tag=CXX --mode=link gcc -pthread -g -O2 -o libtest.la lib.lo
ar cru .libs/libtest.a .libs/lib.o
ranlib .libs/libtest.a
creating libtest.la
(cd .libs && rm -f libtest.la && ln -s ../libtest.la libtest.la)
if g++ -DHAVE_CONFIG_H -I. -I. -I. -I/usr/include/stlport -pthread -g -O2 -MT main.o -MD -MP -MF ".deps/main.Tpo" -c -o main.o main.cc; \
then mv -f ".deps/main.Tpo" ".deps/main.Po"; else rm -f ".deps/main.Tpo"; exit 1; fi
/bin/bash ./libtool --tag=CXX --mode=link gcc -pthread -g -O2 -o cxxtest main.o -lstlport libtest.la
gcc -pthread -g -O2 -o cxxtest main.o -lstlport ./.libs/libtest.a
make[1]: Leaving directory `/home/builder/autot++'
builder@bubt610:~/autot++$ ldd cxxtest
linux-gate.so.1 => (0xffffe000)
libstlport.so.5.0 => /usr/lib/libstlport.so.5.0 (0xb7e81000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7e76000)
libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb7e63000)
libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7d2f000)
/lib/ld-linux.so.2 (0xb7f15000)
libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb7d09000)
builder@bubt610:~/autot++$ ./
autom4te.cache/ config.sub depcomp .libs/
config.guess configure .deps/ libtool
config.status cxxtest install-sh missing
builder@bubt610:~/autot++$ ./cxxtest
Hello, world!
Hello from void printHello()
builder@bubt610:~/autot++$ _

По сравнению с предыдущим добавился файлик lib.cc, собираемый в convenient library libtest.la:

builder@bubt610:~/autot++$ cat lib.cc
#include <iostream>

void printHello(void)
{
std::cout << "Hello from " << __PRETTY_FUNCTION__ << std::endl;
}

builder@bubt610:~/autot++$ _

Компилятор - gcc version 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5).

Если не можется, могу этот же тест на дебиане-3.1 прогнать, на других системах - увольте, это придется под них собранный stlport искать.