хочу задать странный вопрос.
вот я сам программирую не первый год на с под unix, ну и все мои программы(консольные) собираются просто gcc mycode.cА вот когда начинаешь ставить что нибудь из порта начинаешь ужасаться.
./configure - когда я на него смотрю я думаю о том сколько месяцев ушло у чувака что бы написать его ....
когда начинается make Тоже ужасно, всегда сплошные ключи куча длинных строк.Скорее всего, я чего то не знаю.:)
Возникают вопросы. Кто нибудь из присутсвующих обладает подобным уровнем знаний? Что и где надо читать что бы писать такие вот проги? То есть, что бы там был файл configure который бы все чекил и т.п. Как и что писать в Makefile? Как постигнуть эту громаду ключей? Ведь мне кажется не возможно все это знать одному человеку, либо всем этим людям за 30 или даже за 40 и они успели все это переварить. Или же есть какие инструменты? Подскажите!
automake
autoconf
m4
automake
autoconf
m4
KDevelop ... :-DP.S.: значит ты не продуктивно писал... раз ничего не знаешь по прошествии стольких лет. :-)
>automake
>autoconf
>m4
>KDevelop ... :-D
>
>P.S.: значит ты не продуктивно писал... раз ничего не знаешь по прошествии
>стольких лет. :-)
Ну продуктивность вопрос спорный. То что я писал не нуждалось во всем этом.
>хочу задать странный вопрос.
>вот я сам программирую не первый год на с под unix, ну
>и все мои программы(консольные) собираются просто gcc mycode.c
>
>А вот когда начинаешь ставить что нибудь из порта начинаешь ужасаться.
>./configure - когда я на него смотрю я думаю о том сколько
>месяцев ушло у чувака что бы написать его ....
>когда начинается make Тоже ужасно, всегда сплошные ключи куча длинных строк.
>
>Скорее всего, я чего то не знаю.:)
>
>Возникают вопросы. Кто нибудь из присутсвующих обладает подобным уровнем знаний? Что и
>где надо читать что бы писать такие вот проги? То есть,
>что бы там был файл configure который бы все чекил и
>т.п. Как и что писать в Makefile? Как постигнуть эту громаду
>ключей? Ведь мне кажется не возможно все это знать одному человеку,
>либо всем этим людям за 30 или даже за 40 и
>они успели все это переварить. Или же есть какие инструменты? Подскажите!
>Щаз не вспонмню, но все юзают копии configure со всеми его тестами написаные каким то умным мужиком. Как правило люди не заботятся чтобы удалять ненужные тесты, а просто правкой добавляют необходимые. Реально чтобы всем этим заниматься нужно довольно долго поработать в отделе тестирования и серьёзно заниматься системным програмированием зная особенности процессоров и ОС.
>Щаз не вспонмню, но все юзают копии configure со всеми его тестами
>написаные каким то умным мужиком. Как правило люди не заботятся чтобы
>удалять ненужные тесты, а просто правкой добавляют необходимые.Не занимайтесь дезинформацией. Код configure автоматически генерируется
на основе набора m4-макросов. autoconf+automake+m4 - и все дела.>Реально чтобы всем этим заниматься нужно довольно долго поработать
>в отделе тестирования и серьёзно заниматься системным програмированием
>зная особенности процессоров и ОС.Особенности ОСей знать и правда неплохо, а что до процессоров - то это
вряд ли. Чай не на ассемблере люди пишуть ;-)
>>Щаз не вспонмню, но все юзают копии configure со всеми его тестами
>>написаные каким то умным мужиком. Как правило люди не заботятся чтобы
>>удалять ненужные тесты, а просто правкой добавляют необходимые.
>
>Не занимайтесь дезинформацией. Код configure автоматически генерируется
>на основе набора m4-макросов. autoconf+automake+m4 - и все дела.
А набор m4-макросов обычно берётся из дистрибутива Red Hat, сейчас не
помню, как называется этот rpm.
Так, что товаришчь в целом прав, и дезинформации в его ответе немного.>>Реально чтобы всем этим заниматься нужно довольно долго поработать
>>в отделе тестирования и серьёзно заниматься системным програмированием
>>зная особенности процессоров и ОС.
>
>Особенности ОСей знать и правда неплохо, а что до процессоров - то
>это
>вряд ли. Чай не на ассемблере люди пишуть ;-)
Да и особенности ОС сводятся обычно к степени стандартности их реализаций
стандартных библиотек и степени наличия оных. C для того и нужен, чтоб
везде компилироваться и нигде не работать :)
>>>Щаз не вспонмню, но все юзают копии configure со всеми его тестами
>>>написаные каким то умным мужиком. Как правило люди не заботятся чтобы
>>>удалять ненужные тесты, а просто правкой добавляют необходимые.
>>
>>Не занимайтесь дезинформацией. Код configure автоматически генерируется
>>на основе набора m4-макросов. autoconf+automake+m4 - и все дела.
>А набор m4-макросов обычно берётся из дистрибутива Red Hat, сейчас не
>помню, как называется этот rpm.
Не болтайте ерундой. Это GNU autotools. Есть в каждом дистрибутиве.
>>А набор m4-макросов обычно берётся из дистрибутива Red Hat, сейчас не
>>помню, как называется этот rpm.
>Не болтайте ерундой. Это GNU autotools. Есть в каждом дистрибутиве.
Об чём речь? Об autotools или об rpm пакете со страндартными макросами
для autoconf из дистрибутива Red Hat?
Если помните его имя, так нацарапайте здесь, а то я призабыл, а искать лень.
>а искать лень.
http://autoconf-archive.cryp.to/
Собственно, ещё лучше подходит.
>Так, что товаришчь в целом прав, и дезинформации в его ответе немного.Насчёт этого прочие люди уже ответили.
>Да и особенности ОС сводятся обычно к степени стандартности их реализаций
>стандартных библиотек и степени наличия оных.Такой оптимизм полезен для поддержания морального духа.
Но вреден при планировании.>C для того и нужен, чтоб везде компилироваться и нигде не работать :)
Наветы, наветы... ;)
Впрочем, оный "чистый" C я и сам не очень люблю. Писанины многовато.
>>Так, что товаришчь в целом прав, и дезинформации в его ответе немного.
>
>Насчёт этого прочие люди уже ответили.
Не заметил.
Интересно бы прикинуть процентное соотношение макросов, написанных своими
кривыми ручками по сравнению с оными, скопированными откуда-нибудь ещё
(хоть бы с того ресурса, который я упоминал).
Я полагаю, товаришчь был прав в главном: всё Умный Дядя уже написал, наша
задача вырезать и копировать, но тогда ещё проще -- сам configure
скопировать не меняя вовсе, всё равно толку-то...>>Да и особенности ОС сводятся обычно к степени стандартности их реализаций
>>стандартных библиотек и степени наличия оных.
>
>Такой оптимизм полезен для поддержания морального духа.
>Но вреден при планировании.
Да ну Вас. Ну давайте возьмём примерчики конкретных полезных программок,
посмотрим на их configure. Проверки сплошь из одного и того же набора.
Ну понятно, можно сказать, что может быть зависимость от чего-то
потоньше, вроде разрядности int (так и от типа процессора можно придумать
зависимость). Только дело в том, что если программулина от таких вещей
зависит, ей никакой autoconf не поможет выжить.
>>Насчёт этого прочие люди уже ответили.
>Не заметил.
>Интересно бы прикинуть процентное соотношение макросов, написанных
>своими кривыми ручками по сравнению с оными, скопированными
>откуда-нибудь ещё (хоть бы с того ресурса, который я упоминал).
>Я полагаю, товаришчь был прав в главном: всё Умный Дядя уже
>написал, наша задача вырезать и копировать, но тогда ещё проще
>-- сам configure скопировать не меняя вовсе, всё равно толку-то...
>Написанный "умным дядей" проверок на свете очень много, и в каждом
конкретном проекте из них нужны, мягко говоря, не все. Плюс генерация
Makefile'ов - вопрос вообще отдельный, с проверками слабо связанный.
Состав зависимостей, структура самого проекта у всех разная, а
в генерированном коде от этих вещей много чего зависит, причём это
зависимое не раз и не два дублируется. Совсем не меняя configure
его копировать в другой проект - занятие и вовсе бесполезное.>>>Да и особенности ОС сводятся обычно к степени стандартности
>>>их реализаций стандартных библиотек и степени наличия оных.
>>
>>Такой оптимизм полезен для поддержания морального духа.
>>Но вреден при планировании.
>Да ну Вас. Ну давайте возьмём примерчики конкретных полезных программок,
>посмотрим на их configure. Проверки сплошь из одного и того же набора.
>Ну давайте. На память: apache, tomcat-jk, mc, m4, xemacs.
Состав проверок, скажем так, не идентичный.>Ну понятно, можно сказать, что может быть зависимость от чего-то
>потоньше, вроде разрядности int (так и от типа процессора можно придумать
>зависимость). Только дело в том, что если программулина от таких вещей
>зависит, ей никакой autoconf не поможет выжить.В таких программулинах обычно на каждый такой случай - свой отдельный
кусочек кода, подключаемый на соответствующих системах. Писать проверки
приходится обычно как раз для того, чтобы определить, когда какой
кусочек юзать и в какой вариации (сиречь с каким дополнительным набором
макросов).
>Я полагаю, товаришчь был прав в главном: всё Умный Дядя уже написал,
>наша
>задача вырезать и копировать, но тогда ещё проще -- сам configure
>скопировать не меняя вовсе, всё равно толку-то...
>>Ну давайте возьмём примерчики конкретных полезных программок,
>посмотрим на их configure. Проверки сплошь из одного и того же набора.
>
>Ну понятно, можно сказать, что может быть зависимость от чего-то
>потоньше, вроде разрядности int (так и от типа процессора можно придумать
>зависимость). Только дело в том, что если программулина от таких вещей
>зависит, ей никакой autoconf не поможет выжить.Открою вам баальшой секрет: все эти страшные configure и не менее страшные Makefile (а вы в них заглядывали?) получаются из гораздо менее страшных файлов configure.in (или configure.ac), который лежит в корне проекта, и Makefile.am, которые лежат в каждой поддиректории этого же проекта. Эти файлы, таки да, пишутся руками исходя из специфики данного проекта. А вот протом на сцену выходят autoconf и automake:
autoconf из configure.in делает configure,
automake из configure.in и Makefile.am делает Makefile.am.