Вот радость да какая для гентушников... ;)

Большие проекты не используют configure. Большие проекты едут на своем велосипеде.

хм, зачёт.

>>Добавить содержимое файла dolt.m4 в acinclude.m4.

так он же добавится в aclocal.m4 ?

У него во Future Directions первым пунктом стоит: * Support GNU/Linux on architectures other than x86 and x86-64. I think most will work with exactly the same compiler flags, but I didn't want to add any architecture I couldn't test. * Support other systems.

Чем больше архитектур будет поддерживать скрипт, тем больше будет увеличиваться и его размер. Фактически это попытка заново написать libtool.

>позволяет сократить время сборки больших проектов примерно вдвое.

4.2

Где ссылка на тесты?

Что только люди не придумают, лишь бы CMake и Scons не использовать... сокращение времени сборки - не отменяет убогости automake/autoconf.

Судя по "I think most will work with exactly the same compiler flags, but I didn't want to add any architecture I couldn't test" , больше ничего дописывать не надо, надо только затестить, всё ли будет работать.

Прекратите насиловать труп.

Идиод, сходи по ссылке!

Вот что написано в словаре:
dolt
1> дурень, болван, олух

Идиот, сходи по треду по ссылке!

EDS with libtool 1.5.26-3

real    4m35.934s
user    3m38.786s
sys     0m52.855s

EDS with libtool 2.1 (2.1a+cvs1.2525+20071016-1)

real    4m10.648s
user    3m37.994s
sys     0m26.578s

EDS with dolt

real    3m40.974s
user    3m4.448s
sys     0m31.406s

Заметь, dolt выигрывает у libtool-2.1, но не сильно.
libtool-2.2 работает ещё быстрее.

> Увеличение скорости сборки достигается за счет того, что логика переносится из скриптов, вызываемых командой make для компиляции каждого файла, в скрипт configure.

Пахнет глюками заради сомнительного увеличения скорости.

теперь красноглазие начнёт распространяться в два раза быстрее....

Они совсем там рехнулись что-ли?

autohell 1.1 ?

Нафиг-нафик. И так хорошо.

Есть такое оборот: "исторически сложилось"

Да, в новых проектах надо избегать autotools,
но прежние проекты остаются.

> олько в ОС Linux на процессорах семейств x86 и x86_64

Это как? Автору было лень дописать десяток строк, вызывающих определялку системы?

> Увеличение скорости сборки достигается за счет того, что логика переносится из скриптов, вызываемых командой make для компиляции каждого файла, в скрипт configure.

Офигеть. Для маленьких проектов уже сейчас configure работает дольше чем сам make. Что же будет дальше...

>Вот радость да какая для гентушников... ;)

да как то не критично. а вы об этом хотите поговорить?

Применение autotools вообще неоправданно.

Во-первых, создание autotools-скриптов слишком трудоемко, и документация отвратительная.

Во-вторых, компиляция идет вдвое медленнее, чем могла бы - по сравнению с обычным Makefile, тупо написанным руками.

Разумная альтернатива - это CMake. Достоинства по сравнению с autotools:

- Вдвое быстрее компиляция

- Прекрасная документация

- Простота написания файлов проекта и легкость их чтения/исправления

В печку ее, Зина!

> Что только люди не придумают, лишь бы CMake и Scons не использовать...

1. Учить еще один ублюдочный недоязычок я не собираюсь.
2. Разбираться с глюками CMake я не собираюсь.
3. Упрашивать юзверей установить CMake, Scons я не собираюсь.

Поэтому -- $SUBJ.

> сокращение времени сборки - не отменяет убогости automake/autoconf.

На скольки архитектурах/платформах собирается Ваше поделие?

> Автору было лень дописать десяток строк, вызывающих определялку системы?

Процесс сборки библиотек на разных ОС/архитектурах _очень_ сильно отличается.
Так что будет это далеко не десяток строк. Благодаря libtool'у знают об этом
весьма немногие. Автор, похоже, в их число не входит. Как и присутствующие
здесь любители скунсов, CMake'ов, и прочей забавной живности.

> Учить еще один ублюдочный недоязычок я не собираюсь.

Ублюдочный недоязычок - это скорее m4, лол.

Алсо, SCons написан на питоне, который в наше время все приличные люди знают, и который стоит у всех. Сам scons можно положить прямо в дистрибутив, всё равно он займёт там меньше места, чем configure и прочая лебеда.

> SCons написан на питоне

И потому идет в /dev/null. Вместе с питоном.

> который в наше время все приличные люди знают,

Приличные люди не занимаются изучением [censored] недоязычков.

> и который стоит у всех.

Разучиваемя говорить за всю сеть (C).

Я малость пофиксил

> autoconf написан на m4

И потому идет в /dev/null. Вместе с m4.

> который в наше время все приличные люди знают,

Приличные люди не занимаются изучением [censored] недоязычков.

> и который стоит у всех.

Разучиваемя говорить за всю сеть (C).

> 1. Учить еще один ублюдочный недоязычок я не собираюсь. Твоя проблема. ССЗБ.

> 2. Разбираться с глюками CMake я не собираюсь. Сколько глюков CMake тебе известно? Мне, после пары лет работы с ней - 2-3, из которых на сегодня остался один, и тот - просто особенность CMake, описанная в доках (feature).

> 3. Упрашивать юзверей установить CMake, Scons я не собираюсь. Если это юзвери - это не их дело. Если это программеры - им пора уже это иметь. Это же инструменты, а не роскошь.

> На скольки архитектурах/платформах собирается Ваше поделие? Мое 'поделие' содержит обе build system - autotools и CMake. Собирается на Win/Lin(x86,x86_64,MIPS)/BSD/Solaris/HPUX/AIX/OSX. Остальное просто не тестировал - не было нужды.

А ты что, серьезно думаешь, что autotools хоть что-то делает лучше, чем остальные?

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

> Сколько глюков CMake тебе известно?

1. library versioning, точнее, полное его отсутствие. libtool'у достаточно
сказать -version-info $(CURRENT):$(REVISION):$(AGE), и на каждой из
поддерживаемых платформ он сделает все "как надо". CMake -- пляска с бубном.

2. Много очевидных правил сборки (например, парсеров на lex/yacc) приходится
писать вручную.

3. Придурковатый язык.

> из которых на сегодня остался один, и тот - просто особенность CMake,
> описанная в доках (feature).

Как все просто, оказывается! Описываешь глюк в документации -- и все, это
теперь фича!

> Если это программеры - им пора уже это иметь. Это же инструменты, а не роскошь.

Чего ради? Что такого могут эти инструменты, чего не может autoconf/libtool/automake?

> Мое 'поделие' содержит обе build system - autotools и CMake.

Жизнь слишком коротка, чтоб поддерживать более одной системы сборки.

> Вообще, для меня повышение скорости компиляции вдвое бьет почти любой
> аргумент.

1. Не пудрите мне мозг. Компилятор -- тот же самый. make -- тот же самый.
Какое, в пень, повышение скорости? За счет чего?

2. Даже если это мифическое "повышение скорости" есть -- изучение CMake
займет гораздо больше. Лучше за это время освоить что-нибудь полезное.
Или просто отдохнуть.

Просто ты зомбирован.

> Не пудрите мне мозг. Компилятор -- тот же самый. make -- тот же самый. Какое, в пень, повышение скорости? За счет чего?

А ведь ты дебил, однако. Libtool - это скрипт, и его работа отъедает около половины времени сборки. Ещё немало времени отнимает configure. Ещё немало времени отнимает перегенерация мейкфайлов во время разработки.

А если хочешь конкретных примеров - когда KDE перевели с autohell на cmake, он стал собираться вдвое быстрее, можешь сам проверить.

Я сам кого угодно

> Просто ты

Запарили тыкать, ептыть. Я что с Вами, на брудершафт пил?

> зомбирован.

Нет. Просто я взял и проверил.

> А ведь ты дебил, однако.

Следите за речью. А то ведь в жизни за такие слова и огрести недолго.

> Libtool - это скрипт,

Да что Вы говорите?

> и его работа отъедает около половины времени сборки.

Время его работы пренебрежимо мало по сравнению с собственно компиляцией.
Потому как shell (особенно какой-нибудь ash, заточенный именно для обработки
скриптов, а не для интерактивной работы) куда быстрее g++, а fork() -- еще
быстрее.

> Ещё немало времени отнимает configure.

Аналогично.

> Ещё немало времени отнимает перегенерация мейкфайлов во время разработки.

А CMake -- он, наверное, пирожки печет, а не генерит Makefile'ы.

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

> Всё с тобой, быдлом, ясно. Очередной адепт позавчерашних технологий.

Очередной хам и изобретатель велосипедов. С квадратными колесами.

P.S.

Прекращайте хамить по-добру, по-здорову.