программистское

[avva]

Читал документацию gmake. Смеялся сквозь слёзы.

Comments

[avva.livejournal.com]

Я разве сказал, что плохой? Я сказал, что смеялся сквозь слёзы.

Над всей этой навороченной ad-hoc кучей невнятного, неинтуитивного синтаксиса, эзотерических комбинаций служебных символов, ни с чем не совместимых собственных расширений, постоянной путаницы с переменными среды, и прочих прелестей.

[sartoris.livejournal.com]

Толя, прости, но ты не прав. Уродство Makefile начинается там, где совершенно непонимающий принцип работы make человек изобретает велосипед.

Еще одна деталь: Makefile != Project file. Цель Makefile - указывать на последовательную взаимосвязь модулей. Вторичная цель - собирадь модули в кучу, пользуясь уже определенной взаимосвязью. Все остальные применения - изобретения "умельцев". Что ж поделаешь если GNU make очень уж "открыт" для разного рода издевательств?

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

Кстати - о последнем. С тех пор, как я преодолел "образовательный барьер" во всем что касается m4 (в частности благодоря автотулзам) я вообще не понимаю, зачем люди пишут СВОИ моторы обработки шаблонов... И себя не понимаю, когда вижу какую-то муть, написаную 3-4 года назад:))))

[yuridichesky.livejournal.com]

Аппликативный язык, плюс куча традиций, плюс длинная история. И при этом еще работатет. Может, еще нас всех переживет.

Кстати, а какие альтернативы?

[dimrub.livejournal.com]

http://ant.apache.org/

[cmm.livejournal.com]

Ant, Scons, и вообще написать сборщик — не бином Ньютона, прямо скажем.  часто бывает сильно проще, чем насиловать make.

[sartoris.livejournal.com]

Хмм... Да... Проще. А потом кому-нибудь придется этот спец-сборщик насиловать... Точнее себя им насиловать. Вплоть до перевода всего на стандартный MAKE. (Мне приходилось это делать дважды)

На самом деле СБОРЩИКОМ является именно autotools. А make это всего-лишь центральный инструмент (на равне с gcc, ld и так далее). Любой написаный "от-руки" или с помощью своих скриптов makefile - это уже "свой" сборщик.

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

[cmm.livejournal.com]

> Хмм... Да... Проще. А потом кому-нибудь придется этот спец-сборщик насиловать... Точнее себя им насиловать. Вплоть до перевода всего на стандартный MAKE. (Мне приходилось это делать дважды)

по моему опыту, в любом проекте серьёзной величины написание/поддержка makefile'ов и окружающих скриптов/среды/etc является нормальной такой задачей где-то на одну восьмую (как минимум одну шестнадцатую) разработчика.  посему есть смысл потратить силы и время на дизайн и прочая.  ситуация, в которой каждый участник проекта должен лезть в эту муть при каждой надобности — при всей своей повсеместности, нездоровая.  но, разумеется, если ожидать что каждый должен мочь — тогда чем "стандартнее" инструментарий, тем лучше.

[sartoris.livejournal.com]

Угум... В таком ключе я как-то раз работал... Сначала меня крыл матюками "изобретатель" makefile. Потом, когда я наконец-то прочел его изобретение и обнаружил, что у него makefile выполняет функции batch-script обложил матюгами уже я его.

А потом мне пришлось тихо всё затачивать под скромный, простой и ДОКУМЕНТИРОВАНЫЙ механизм автоматического генерирования Makefile. Правда в этом случае не было надобности в portability. Иначе бы зарыблся бы в автотулзы.

[avva.livejournal.com]

Я выше написал об альтернативе: мыло с верёвкой ;)

[yuridichesky.livejournal.com]

Ну что я могу сказать? Полюбите make (awk, sed, ...), и он отплатит вам взаимностью. :)
Только чувство должно быть искренним...

[avva.livejournal.com]

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

[dimrub.livejournal.com]

Ант рулит, короче.

[sartoris.livejournal.com]

Кхе-кхе. Где он рулит-то? Я его ТРИ раза пытался пробовать... Мудохался пол дня, переписывал, переделывал всё... А потом он у меня на сотом файле где-то загнулся. Очень был разочарован. Тормозит страшно... Многотредовость не поддерживает. Соображает плохо. И главное примитивных сборок с ним так быстро, как с make не сделаешь...

[dimrub.livejournal.com]

Мейк проще, чем ант? Ну ты силен :)

[sartoris.livejournal.com]

program: program.c
gcc -o program program.c -I/usr/include -L/usr/lib

Что может быть, пардон, проще? Другой синтаксис? Так какая разница какой он - синтаксис?

[perfect-man.livejournal.com]

program: program.o

[sartoris.livejournal.com]

Ну-ну.... И откуда make возьмет этот program.o? Из пальца, опять-таки высосет? (hint: не всякий make знает, что .o это значит "строй object file из файла .c")

[perfect-man.livejournal.com]

Наверное, там же, где он возьмет gcc. Тем же способом, которым достанет библиотеки из жестко прописанной директории.

[sartoris.livejournal.com]

Это всё зависит от того, как машина сконфигурирована. На современном линуксе это может и проканать (тоже, кстати, не всегда). А где-то такое написание не катит.

Всё-таки если и писать Makefile в ручную, то по правилам. С определением компилятором, путей, взаимосвязей исходников. Особенно если хочется поиграться с precompiled-headers (я правда с ними еще не игрался на GCC, но говорят неплохо работают)...

[perfect-man.livejournal.com]

Конечно. Но вероятность того, что такое написание прокатит -- больше, чем вероятность того, что компилятор C называется gcc. Он ведь опять-таки все больше на современном линуксе. Несколько логичнее было бы писать просто cc, наверное (хоть и ненамного). Вообще, странно надеяться на переносимость рукотворных Makefiles.

Как-то так.

[sartoris.livejournal.com]

О! Так об этом и речь. Makefile не переносим в "чистом виде". Зато если что-то такое, быстренькое - очень даже удобно. Для переноски же есть всё тот же Autoconfig. Почему при этом надо плакать (или смеяться) я не знаю...

(gcc действительно отнюдь не везде стоит - ваша правда - надо всё-таки писать:

CC=gcc
CFLAGS=-I/usr/include -L/usr/lib

program: program.c
$(CC) -o program program.c $(CFLAGS)

)

[cmm.livejournal.com]

или даже как-нибуд' так:

my-program: exe
  objects: one two
  libs: foo bar

что в переводе в голый make с соответствующей конфигурацией выглядело бы как-то так:

my-program: one.o two.o libfoo.a libbar.a
  gcc -o my-program one.o two.o -lfoo -lbar

но вед' хрен там, публика предпочитает мыслит' в духе "а где у нас тут gcc".  отсутствие вкуса к нормал'ному декларативному синтаксису влечет за собой замусоренност' мышления.  во многих отношениях бол'шинство современных айтишников по сию пору работает (мозгами) на ассемблере, и считает что так и нужно.

а где у нас тут gcc

[stas]

Проблема, однако, тут в том, что как только захочешь оторваться от земли и воспарить в высоты декларативного синтаксиса, так оказывается, что на каком-нибудь HP-UX make таки не знает, "где тут у нас gcc" и как правильно говорить -lfoo. Или знает, но в версии CVS, которая по случайности уже полгода как не поддерживает вашу версию OS, потому что слишком старая и у разработчиков её нету. И возникает интересный выбор - то ли изучать сорсы всех этих штук и править вручную, то ли опускаться в дебри ассемблера и писать все правила заново - но зато чтобы работали раз и навсегда.

Я по сходным причинам отказался от использования в наших проектах autotools, которые якобы сильно помогают строить shared libraries. Они-то помогают, на линуксе и т.п., где и так с этим проблем нету. А вот как на что поэкзотичнее перейти - кино и немцы начинается. Легче вручную написать все нужные команды, чем разбираться, почему libtool уверен, что на этой системе динамические библиотеки обязаны строиться анальным способом с выподвыперевертом.

Re: а где у нас тут gcc

[cmm.livejournal.com]

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

дык я, собственно, к чему?
ежели abstraction boundary пролегает по маршруту к gcc и названию флага для делания shared library, то натурал'но оказывается.  еще и не такое может оказат'ся.
потому как строит' абстракцию на уровне плоской текстуал'ной "макро"-модстановки отдел'ных слов в makefile — как и было сказано выше, практика хот' и повсеместная, но нездоровая.

это с одной стороны.  с другой стороны, натурал'но, подобный подход к многоплатформенности позволяет испол'зоват' всякие эвристические по сути своей инструменты типа autoconf'а.  потому как если надо знат' не как тут gcc зовут, а как тут shared library строит', то на autoconf'е в сочетании с make'ом сил'но далеко уехат' не получится. :)

(а еще очен' хотелос' бы добыт' фонетическую раскладку кириллицы для Windows, которая не совала бы мягкий знак, твердый знак и букву "йо" в места, недоступные для лаптоповой клавиатуры.  так что простите за неровный почерк. :))

[stas]

всей этой навороченной ad-hoc кучей невнятного, неинтуитивного синтаксиса, эзотерических комбинаций служебных символов, ни с чем не совместимых собственных расширений

Это вы про Perl говорили? ;)