Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+133
lc = $(subst A,a,$(subst B,b,$(subst C,c,$(subst D,d,$(subst E,e,$(subst F,f,$(subst G,g,$(subst H,h,$(subst I,i,$(subst J,j,$(subst K,k,$(subst L,l,$(subst M,m,$(subst N,n,$(subst O,o,$(subst P,p,$(subst Q,q,$(subst R,r,$(subst S,s,$(subst T,t,$(subst U,u,$(subst V,v,$(subst W,w,$(subst X,x,$(subst Y,y,$(subst Z,z,$1))))))))))))))))))))))))))
VAR = MixedCaseText
LOWER_VAR = $(call lc,$(VAR))
all:
@echo $(VAR)
@echo $(LOWER_VAR)
как реализовать портабельно lowercase функцию в GNU Make.
как же я тебя временами лублу, мэйк.
ЗЫ было случайно найдено в http://stackoverflow.com/questions/664601/in-gnu-make-how-do-i-convert-a-variable-to-lower-case
Запостил: 
Dummy00001,
06 Октября 2014
Follow us!
вот так реализуется strlen():
235 символов, ёпта.
Какой весёлый код.
Зачем в make lowercase и strlen? Имхо, это уже далеко за областью применимости make...
Оно зависимости то с горем-пополам трекает, а вы от него работу со строками требуете.
Запилить то можно. Но в результате к куче кривых билд-систем добавится еще одна (картинка-с-xkcd-о-стандартах.png)...
по моему опыту очень мало людей знают хотя бы одну систему досканально. почему грамотно переписать ни у кого и не получается.
а чисто по приколу, очень простая, нативно-рекурсивная билд система не должна быть сильно сложной. самая большая проблема это, как обычно, алгоритм который говорит что в каком порядке должно билдится. (модель данных (которая у меня в голове сидит) меньше 10 объектов. но для алгоритма зависимостей может еще что понадобится.)
Это то как раз несложно... Да и мейк с этим вполне справляется.
Проблемы начинаются от того, что народу хочется "писать поменьше" (wildcard правила, шаблоны, архетипы и т.п.), "чтобы зависимости между проектами были" (и начинается скрещивание ужа и ежа билд системы и пакетного менеджера), "чтобы uppercase не приходилось писать через жопу" (из-за этого к системе прикручивается язык программирования, в худшем случае - изобретается своё говно, аля cmake), "чтобы проекты под вижуалку/клипсу/идею генерило", "чтобы пакеты под дебиан собирало, а заодно и msi" и т.п.
В результате получается монстр, доку по которому досканально никто осилить не может, но при этом половина нужных фич все равно не поддерживается нативно, и их приходится допиливать на невменяемом говне в духе sh+m4 или языка, встроенного в cmake...
Чем cmake то не угодил? Вроде очень гибкая система.
2. Много багов. Если юзаешь не распоследнюю версию, во что-нибудь да наступишь.
3. Приходится много писать, можно и нужно меньше.
4. Кочующие из проекта в проект волшебные рецепты для поиска библиотек. Даже для сборки чего-то тривильного приходится искать волшебный файлик или писать 100-150 строк костылей самому.
5. Зависимости через ExternalProject? Поиграться ещё нормально, но со стороны это всё же выглядит как костыли.
А так пользоваться можно, за неимением лучшего.
Не сильно много юзал, но особых багов не встречал. Иногда правда надо было папку вычистить и собрать заново. В сравнении с уродскими make/automake большой шаг вперёд, хоть синтаксис и сильно долбанутый - это верно.
Если б его скрестили с репозиториями библотек и разруливатилем зависимостей, то наверное для всякой мелкой хери большего и не надо.
> Это то как раз несложно...
именно это я имел в виду. если сделать шаг в сторону минимализма, что бы создать хорошую базовую систему, то это и есть самая "сложная" проблема. которая в принципе и не так сложна.
Нормальная - это такая, которая позволяет получать максимум отдачи минимальными затратами.
Т.е. по максимуму DRY, Convention over Configuration, дружелюбность и однородность в человеко-машинном интерфейсе.
> по моему опыту очень мало людей знают хотя бы одну систему досканально.
Я довольно неплохо знаю make, причём ненавижу его всей душой. Писал масштабные мультикомпонентные билды на ant, maven (для него я как-то даже писал плагины), gradle, ковырял gyp вплоть до сорцов, для крестов пока остановился на CMake.
Интересно выглядит http://industriousone.com/premake но его я ещё не пробовал.
Хаскелевый cabal-install отвратителен, но в него заложены хорошие идеи - src-пакеты, декларативные билды, учёт зависимостей, песочницы, поддержка нескольких одновременно установленных версий, интегрированные юнит тесты, etc.
Чего хочется от "нормальной" билд-системы:
- максимально декларативные и короткие билд-файлы. CoC - MUST HAVE.
- поддержка конфигураций.
- параллельные сборки из коробки.
- поддержка обобщённых зависимостей - не только от файла timestamp, но и от опций компилятора или переменных окружения, как в shake.
- пакеты, распространяемые в виде сорцов и учёт зависимостей. MUST HAVE.
- тестовый фреймворк из коробки.
- наличие генератора проектных файлов для популярных IDE.
- удобный скриптовый язык для конфигурации (п.с. kitware, похоже, пробовали lua лет 6-7 назад http://www.cmake.org/Wiki/CMake:Experiments_With_Lua).
- компиляторно-независимые флажки для основных опций. Типа optimize(for_speed), optimize(for_size), optimize(3), и т.п. Но специфичные для копмилятора опции тоже должны поддерживаться.
Сделать всё по-человечески очень сложно, особенно для крестов с их сраным препроцессором, от того пока и не берусь.
вы не одиноки в этом чувстве к мэйку. линух (кернел) реализует неплохую систему на мэйке - но последний раз когда я это ковырял это было около 60К бойлерплейта на чистом мэйке + несколько внутренних специальных тулзов.
> - максимально декларативные и короткие билд-файлы. CoC - MUST HAVE.
"CoC"?
> - поддержка обобщённых зависимостей - не только от файла timestamp, но и от опций компилятора или переменных окружения, как в shake.
первым это делал cons хез знает сколько лет назад. вроде scons это тоже перенял с самого начала.
> - тестовый фреймворк из коробки.
в билд системе??
> - компиляторно-независимые флажки для основных опций.
cons это делал на основе базового окружения (environment), которое наследовалось всем проектом. как показала практика, концепция окружения весьма тривиальна в реализации.
Выше была расшифровка - Convention over Configuration.
Это означает, что пока пользователь следует опщепринятым соглашениям, ему почти не надо ничего конфигурировать.
Грубо говоря, можно кидать инклюдники в include, а исходники в src и всё работает автомагически (хоть с крестами и не так всё просто). Но если хочешь поменять стардартный шаблон - без проблем.
Практика пришла из фреймворков вроде RoR.
мечтайте дальше.
"общеприниятые соглашения" к сожалению часто слишком поверхностные, для того что бы наибольшему возможному количеству пользователей аппелироать.
шаг влево, шаг вправо - и уже нифига непредусмотрено, нифига не поддерживается.
вот про это я и говорю. народ слишком много ожидает от билд системы. поэтому я в голове и пытаюсь сделать насколько только можно минималистическую билд систему которая даже и проверять не будет, нужно ли что-то билдить или нет, а будет просто билдить.
мне недавно нужна была простая нативно-рекурсивная система которая бы просто могла из А в Б (js, css, html) файлы скопировать, может быть прогоняя их через препроцессор внешний. я посмотрел три-четыре системы и потом просто забил: все настолько заточено на языки программирования, все настолько "просто", что чтобы просто подключить и вызвать "cp" на файлы, на tug(? или pug? хез, не помню) мне нужно было строк десять бойлер-плейта написать. а казалось бы.
учитывая состояние документации этих нишевых билд систем - тривиальная задача не предусмотреная системой становится неподъемной проблемой (нет, мне так и не удалось подключить "cp" в течении часа что я себе ответ на это упражнение). мэйк я люто не навижу - но лучше отдокументированой системы я еще не видел. в конце перестал муйдохатся и написал пару шелл скриптов которые это все безусловно молча делают. потому что на скриптах делать рекурсию проще.
ЗЫ shake не смотрел, потому что на хаскеле. у меня тут максимум перл и питон в chroot'e есть. большая часть тулзов которые смотрел оказались писаные на жабе, но я их уже просто по состоянию документации заранее отфильтровывал. то что пытался ковырять тоже на жабе было написано, но я просто хотел посмотреть на что-то новое.
Мне не интересна билд-система общего назначения. Мне нужна система с сильным акцентом на сишкокресты, с возможностью реализации чего угодно при помощи встроенного скриптового языка. Gradle на самом деле весьма удобен, хочется чего-то похожего для крестов.
> shake не смотрел,
Да и я особо не смотрел. Для билдов, кмк, нужен всё же скриптовый язык.
вот оно опять.
если билд система не способна на general purpose, то она скорее всего плохая билд система.
синтакс шугар, генераторы, плагины - все можно прикруть позже. но если нет сильной базы - гибкой надежной general purpose билд системы - то фишки как бы и прикручивать не к чему.
а если и прикрутишь, то опять получится в последствии косяк, потому что под новые нужды (которые появляются чаще чем народ думает) уже и не подходит.
Это всё понятно. Нормальный скриптовый язык нужен как раз для general purpose. Параллельное выполнение DAG задач в любом случае писать придётся.
Если не проектировать систему так, чтобы в неё нормально вписались основные юзкейсы и плагины.
Что это решит?
1. Необходимость реализовывать функции по работе с типами данных не интересующими билд-систему (строками, файлами, потоками, сокетами и т.д.)
2. Переносимость (хотя бы в теории).
3. Интеграцию (или, по крайней мере возможность) с другими системами похожего плана, если к ним есть доступ из языка на котором реализована билд-система.
С другой стороны: проблемы типа "для одного языка такой плагин существует, а для другого - нет..." но, все равно, мне кажется, что такой подход был бы лучше.
помимо очевидной chicken and egg проблемы (who builds the build system?), мне кажется что это желание больше мотивировано убогостью существующих систем, нежели чем реальными проблемами.
но к твоим требованиям (тот же встроеных тест фрэймворк) это может быть и на самом деле лучше подходит.
как по мне, надежная система писаная на перле или питоне или луа, и на них же расширяемая, была бы вполне достаточна.
ЗЫ только сейчас заметил что нативная рекурсивность у тебя даже не стоит требованием. что скорее всего значит что reproducible builds у тебя не приоритет. это большой контраст по отношению к моим проблемам с и ожиданиям от билд системы.
1. `cd app; build hello_world` и `build app/hello_world` имеют аналогичный эффект.
2. если `app/hello_world` зависит от `lib/libprintf.so`, то в (1), в независимости как ты вызываешь билд, так же собирется и `lib/libpritnf.so`.
например мэйк умеет только опускатся в подкаталоги. вызов мэйка из подкаталога будет билдить только то что находится в этом подкаталоге, и ничего более.
недостаток рекурсивных систем в том что каждый вызов билда, даже если поменялся только один файл, будет грузить в память весь проект целиком.
Это я бы сказал естественное пожелание, настолько, что я даже не стал его упоминать. Оно, разумеется, MUST HAVE. Такое почти умеют GYP и CMake. И билды у них не зависят от того, откуда ты генератор запустил, все пути в билд-файлах считаются относительно билд-файла.
> даже если поменялся только один файл, будет грузить в память весь проект целиком.
Кстати, интересна возможность инверсии графа зависимостой для поддержания "реактивного режима", в котором система интерактивно пересобирает файлы при их изменении, как tup (http://gittup.org/tup/). В похожем режиме умеет работать sbt, который скалку собирает.
Далеко не всегда даже теоретически возможно сделать воспроизводимые билды (например, если врезультате билда нужно получить что-то уникальное). Т.е. воспроизводимость будет только препядствовать решению задачи. Другая проблема - далеко не все компиляторы всех языков могут создать одинаковый результат в идентичных условиях. Т.е. система, которая бы делала это требования обязательным не могла бы сотрудничать с большим количеством существующих инструментов.
Рекурсивные билды - это проблема людей компилирующих Си/С++, потому что у них так проекты построены, что это нужно. Во многих системах об этой проблеме даже не слышали никогда.
Кто будет компилировать систему? А Мейк что-ли не нужно чем-то собирать? Это проблема любого компилятора (дело чести любого ЯП написать компилятор его компилирующий на этом же ЯП).
Другими словами, если у нас есть рецепт того как нужно сделать систему, то ее хоть машинными кодами можно будет набрать (естесственно, не хочется это делать, но такова судьба большинства компиляторов и похожих програм).
естественно слышали. они просто не знают как проблема называется.
в любом языке где есть библиотеки и интерфейсы, эта проблема существует.
в той же жабе, изменил interface - нужно все что трогает интерфейс перекомпилить, что бы по крайней мере проверить что код соответствует интерфейсу.
На самом деле под "рекурсивным билдом" можно понимать что угодно. На самом дле обычно подразумевают рекурсивный вызов билд-системы в подкаталогах, который в случае make, как известно, considered harmful (http://aegis.sourceforge.net/auug97.pdf)
Вероятно, @wvxvw понял именно в этом смысле.
Это определение просто не имеет смысла.
Потому что по этому определению все билд системы рекурсивны - просто вызываешь самое себя, как внешнюю комманду, в подкаталоге. (Как это и делает мэйк.)
Проблема не в том что бы опустится по дереву исходников. Проблема *поднятся* *вверх* по дереву исходников. Проблема в билде зависимостей лежащих в *соседних* каталогах.
> http://aegis.sourceforge.net/auug97.pdf
О. а aegis мне много лет назад хвалили. Правда похвалы шли не из самого правильного источника, но глянуть надо будет.
ЗЫ tup тоже гляну. а вдруг.
А, ну ни разу не видел, чтобы кто-то называл это "рекурсивная сборка". Да и название не подходящее.
Это сборка обратных зависимостей, такое действительно мало кто реализует. Кмк, для этого нужна специальная команда, неправильно делать "из коробки".
а я ни разу "рекурсивная сборка" и не говорил.
я говорил "нативно-рекурсивная билд система".
strlen не знаю кому нужен.
мне lowercase & uppercase пригодился бы (почему и гуглил) что бы перетягивать (и унифицировать) переменные из разных частей системы, которые следуют разным соглашениям (типа $(includes) vs. $(INCLUDES)). я хотел просто проверку забомбить: если переменная не найдена, то попробовать ее имя в lowercase & uppercase, и только потом обламываться.
Сайлент попытки никогда ни к чему хорошему не приводили.
++++++++
$(iNcLuDeS)
там конфиги генерятся либо из шела, либо шелом из .c/.h файлов, и в последствии используются в нескольких местах, включая мэйкфайлы. то что изначально предназначено для enum'ов в С использует lowercase имена. для шелла - переменные окружения - uppercase.
мэйк это единственное место где это всё в одно место сливается, почему и выглядит кривовато.
я просто пытался избежать заводить еще один набор переменных (которые все еще раз переименовывают) и хотел просто "искать" нужные значения. добавление/удаления префикса/суффикса на мэйке не проблема - но смена регистра только через внешнюю комманду.