- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
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.10.2014 16:16 # 0
вот так реализуется strlen():
235 символов, ёпта.
gost 07.10.2014 07:38 # +1
Какой весёлый код.
inkanus-gray 07.10.2014 08:22 # 0
bormand 07.10.2014 13:52 # +1
Зачем в make lowercase и strlen? Имхо, это уже далеко за областью применимости make...
Оно зависимости то с горем-пополам трекает, а вы от него работу со строками требуете.
roman-kashitsyn 07.10.2014 14:01 # +2
bormand 07.10.2014 14:08 # +1
Запилить то можно. Но в результате к куче кривых билд-систем добавится еще одна (картинка-с-xkcd-о-стандартах.png)...
roman-kashitsyn 07.10.2014 14:30 # +1
Dummy00001 07.10.2014 14:41 # 0
по моему опыту очень мало людей знают хотя бы одну систему досканально. почему грамотно переписать ни у кого и не получается.
а чисто по приколу, очень простая, нативно-рекурсивная билд система не должна быть сильно сложной. самая большая проблема это, как обычно, алгоритм который говорит что в каком порядке должно билдится. (модель данных (которая у меня в голове сидит) меньше 10 объектов. но для алгоритма зависимостей может еще что понадобится.)
bormand 07.10.2014 15:00 # +1
Это то как раз несложно... Да и мейк с этим вполне справляется.
Проблемы начинаются от того, что народу хочется "писать поменьше" (wildcard правила, шаблоны, архетипы и т.п.), "чтобы зависимости между проектами были" (и начинается скрещивание ужа и ежа билд системы и пакетного менеджера), "чтобы uppercase не приходилось писать через жопу" (из-за этого к системе прикручивается язык программирования, в худшем случае - изобретается своё говно, аля cmake), "чтобы проекты под вижуалку/клипсу/идею генерило", "чтобы пакеты под дебиан собирало, а заодно и msi" и т.п.
В результате получается монстр, доку по которому досканально никто осилить не может, но при этом половина нужных фич все равно не поддерживается нативно, и их приходится допиливать на невменяемом говне в духе sh+m4 или языка, встроенного в cmake...
bormand 07.10.2014 15:08 # 0
laMer007 07.10.2014 15:30 # 0
Чем cmake то не угодил? Вроде очень гибкая система.
roman-kashitsyn 07.10.2014 15:42 # +2
2. Много багов. Если юзаешь не распоследнюю версию, во что-нибудь да наступишь.
3. Приходится много писать, можно и нужно меньше.
4. Кочующие из проекта в проект волшебные рецепты для поиска библиотек. Даже для сборки чего-то тривильного приходится искать волшебный файлик или писать 100-150 строк костылей самому.
5. Зависимости через ExternalProject? Поиграться ещё нормально, но со стороны это всё же выглядит как костыли.
А так пользоваться можно, за неимением лучшего.
3.14159265 07.10.2014 20:20 # 0
Не сильно много юзал, но особых багов не встречал. Иногда правда надо было папку вычистить и собрать заново. В сравнении с уродскими make/automake большой шаг вперёд, хоть синтаксис и сильно долбанутый - это верно.
Если б его скрестили с репозиториями библотек и разруливатилем зависимостей, то наверное для всякой мелкой хери большего и не надо.
Dummy00001 07.10.2014 16:57 # 0
> Это то как раз несложно...
именно это я имел в виду. если сделать шаг в сторону минимализма, что бы создать хорошую базовую систему, то это и есть самая "сложная" проблема. которая в принципе и не так сложна.
roman-kashitsyn 07.10.2014 15:10 # +3
Нормальная - это такая, которая позволяет получать максимум отдачи минимальными затратами.
Т.е. по максимуму 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), и т.п. Но специфичные для копмилятора опции тоже должны поддерживаться.
Сделать всё по-человечески очень сложно, особенно для крестов с их сраным препроцессором, от того пока и не берусь.
Dummy00001 07.10.2014 15:38 # 0
вы не одиноки в этом чувстве к мэйку. линух (кернел) реализует неплохую систему на мэйке - но последний раз когда я это ковырял это было около 60К бойлерплейта на чистом мэйке + несколько внутренних специальных тулзов.
> - максимально декларативные и короткие билд-файлы. CoC - MUST HAVE.
"CoC"?
> - поддержка обобщённых зависимостей - не только от файла timestamp, но и от опций компилятора или переменных окружения, как в shake.
первым это делал cons хез знает сколько лет назад. вроде scons это тоже перенял с самого начала.
> - тестовый фреймворк из коробки.
в билд системе??
> - компиляторно-независимые флажки для основных опций.
cons это делал на основе базового окружения (environment), которое наследовалось всем проектом. как показала практика, концепция окружения весьма тривиальна в реализации.
roman-kashitsyn 07.10.2014 15:47 # 0
Выше была расшифровка - Convention over Configuration.
Это означает, что пока пользователь следует опщепринятым соглашениям, ему почти не надо ничего конфигурировать.
Грубо говоря, можно кидать инклюдники в include, а исходники в src и всё работает автомагически (хоть с крестами и не так всё просто). Но если хочешь поменять стардартный шаблон - без проблем.
Практика пришла из фреймворков вроде RoR.
Dummy00001 07.10.2014 16:03 # 0
мечтайте дальше.
"общеприниятые соглашения" к сожалению часто слишком поверхностные, для того что бы наибольшему возможному количеству пользователей аппелироать.
шаг влево, шаг вправо - и уже нифига непредусмотрено, нифига не поддерживается.
Dummy00001 07.10.2014 15:39 # 0
вот про это я и говорю. народ слишком много ожидает от билд системы. поэтому я в голове и пытаюсь сделать насколько только можно минималистическую билд систему которая даже и проверять не будет, нужно ли что-то билдить или нет, а будет просто билдить.
мне недавно нужна была простая нативно-рекурсивная система которая бы просто могла из А в Б (js, css, html) файлы скопировать, может быть прогоняя их через препроцессор внешний. я посмотрел три-четыре системы и потом просто забил: все настолько заточено на языки программирования, все настолько "просто", что чтобы просто подключить и вызвать "cp" на файлы, на tug(? или pug? хез, не помню) мне нужно было строк десять бойлер-плейта написать. а казалось бы.
учитывая состояние документации этих нишевых билд систем - тривиальная задача не предусмотреная системой становится неподъемной проблемой (нет, мне так и не удалось подключить "cp" в течении часа что я себе ответ на это упражнение). мэйк я люто не навижу - но лучше отдокументированой системы я еще не видел. в конце перестал муйдохатся и написал пару шелл скриптов которые это все безусловно молча делают. потому что на скриптах делать рекурсию проще.
ЗЫ shake не смотрел, потому что на хаскеле. у меня тут максимум перл и питон в chroot'e есть. большая часть тулзов которые смотрел оказались писаные на жабе, но я их уже просто по состоянию документации заранее отфильтровывал. то что пытался ковырять тоже на жабе было написано, но я просто хотел посмотреть на что-то новое.
roman-kashitsyn 07.10.2014 15:50 # 0
Мне не интересна билд-система общего назначения. Мне нужна система с сильным акцентом на сишкокресты, с возможностью реализации чего угодно при помощи встроенного скриптового языка. Gradle на самом деле весьма удобен, хочется чего-то похожего для крестов.
> shake не смотрел,
Да и я особо не смотрел. Для билдов, кмк, нужен всё же скриптовый язык.
Dummy00001 07.10.2014 16:12 # 0
вот оно опять.
если билд система не способна на general purpose, то она скорее всего плохая билд система.
синтакс шугар, генераторы, плагины - все можно прикруть позже. но если нет сильной базы - гибкой надежной general purpose билд системы - то фишки как бы и прикручивать не к чему.
а если и прикрутишь, то опять получится в последствии косяк, потому что под новые нужды (которые появляются чаще чем народ думает) уже и не подходит.
roman-kashitsyn 07.10.2014 16:51 # 0
Это всё понятно. Нормальный скриптовый язык нужен как раз для general purpose. Параллельное выполнение DAG задач в любом случае писать придётся.
Если не проектировать систему так, чтобы в неё нормально вписались основные юзкейсы и плагины.
wvxvw 07.10.2014 15:50 # 0
Что это решит?
1. Необходимость реализовывать функции по работе с типами данных не интересующими билд-систему (строками, файлами, потоками, сокетами и т.д.)
2. Переносимость (хотя бы в теории).
3. Интеграцию (или, по крайней мере возможность) с другими системами похожего плана, если к ним есть доступ из языка на котором реализована билд-система.
С другой стороны: проблемы типа "для одного языка такой плагин существует, а для другого - нет..." но, все равно, мне кажется, что такой подход был бы лучше.
Dummy00001 07.10.2014 16:36 # 0
помимо очевидной chicken and egg проблемы (who builds the build system?), мне кажется что это желание больше мотивировано убогостью существующих систем, нежели чем реальными проблемами.
но к твоим требованиям (тот же встроеных тест фрэймворк) это может быть и на самом деле лучше подходит.
как по мне, надежная система писаная на перле или питоне или луа, и на них же расширяемая, была бы вполне достаточна.
ЗЫ только сейчас заметил что нативная рекурсивность у тебя даже не стоит требованием. что скорее всего значит что reproducible builds у тебя не приоритет. это большой контраст по отношению к моим проблемам с и ожиданиям от билд системы.
roman-kashitsyn 07.10.2014 16:54 # 0
Dummy00001 07.10.2014 17:09 # 0
1. `cd app; build hello_world` и `build app/hello_world` имеют аналогичный эффект.
2. если `app/hello_world` зависит от `lib/libprintf.so`, то в (1), в независимости как ты вызываешь билд, так же собирется и `lib/libpritnf.so`.
например мэйк умеет только опускатся в подкаталоги. вызов мэйка из подкаталога будет билдить только то что находится в этом подкаталоге, и ничего более.
недостаток рекурсивных систем в том что каждый вызов билда, даже если поменялся только один файл, будет грузить в память весь проект целиком.
roman-kashitsyn 07.10.2014 17:19 # 0
Это я бы сказал естественное пожелание, настолько, что я даже не стал его упоминать. Оно, разумеется, MUST HAVE. Такое почти умеют GYP и CMake. И билды у них не зависят от того, откуда ты генератор запустил, все пути в билд-файлах считаются относительно билд-файла.
> даже если поменялся только один файл, будет грузить в память весь проект целиком.
Кстати, интересна возможность инверсии графа зависимостой для поддержания "реактивного режима", в котором система интерактивно пересобирает файлы при их изменении, как tup (http://gittup.org/tup/). В похожем режиме умеет работать sbt, который скалку собирает.
wvxvw 07.10.2014 16:54 # 0
Далеко не всегда даже теоретически возможно сделать воспроизводимые билды (например, если врезультате билда нужно получить что-то уникальное). Т.е. воспроизводимость будет только препядствовать решению задачи. Другая проблема - далеко не все компиляторы всех языков могут создать одинаковый результат в идентичных условиях. Т.е. система, которая бы делала это требования обязательным не могла бы сотрудничать с большим количеством существующих инструментов.
Рекурсивные билды - это проблема людей компилирующих Си/С++, потому что у них так проекты построены, что это нужно. Во многих системах об этой проблеме даже не слышали никогда.
Кто будет компилировать систему? А Мейк что-ли не нужно чем-то собирать? Это проблема любого компилятора (дело чести любого ЯП написать компилятор его компилирующий на этом же ЯП).
Другими словами, если у нас есть рецепт того как нужно сделать систему, то ее хоть машинными кодами можно будет набрать (естесственно, не хочется это делать, но такова судьба большинства компиляторов и похожих програм).
Dummy00001 07.10.2014 17:19 # 0
естественно слышали. они просто не знают как проблема называется.
в любом языке где есть библиотеки и интерфейсы, эта проблема существует.
в той же жабе, изменил interface - нужно все что трогает интерфейс перекомпилить, что бы по крайней мере проверить что код соответствует интерфейсу.
roman-kashitsyn 07.10.2014 17:32 # 0
На самом деле под "рекурсивным билдом" можно понимать что угодно. На самом дле обычно подразумевают рекурсивный вызов билд-системы в подкаталогах, который в случае make, как известно, considered harmful (http://aegis.sourceforge.net/auug97.pdf)
Вероятно, @wvxvw понял именно в этом смысле.
Dummy00001 07.10.2014 18:11 # 0
Это определение просто не имеет смысла.
Потому что по этому определению все билд системы рекурсивны - просто вызываешь самое себя, как внешнюю комманду, в подкаталоге. (Как это и делает мэйк.)
Проблема не в том что бы опустится по дереву исходников. Проблема *поднятся* *вверх* по дереву исходников. Проблема в билде зависимостей лежащих в *соседних* каталогах.
> http://aegis.sourceforge.net/auug97.pdf
О. а aegis мне много лет назад хвалили. Правда похвалы шли не из самого правильного источника, но глянуть надо будет.
ЗЫ tup тоже гляну. а вдруг.
roman-kashitsyn 07.10.2014 18:44 # 0
А, ну ни разу не видел, чтобы кто-то называл это "рекурсивная сборка". Да и название не подходящее.
Это сборка обратных зависимостей, такое действительно мало кто реализует. Кмк, для этого нужна специальная команда, неправильно делать "из коробки".
Dummy00001 07.10.2014 20:07 # 0
а я ни разу "рекурсивная сборка" и не говорил.
я говорил "нативно-рекурсивная билд система".
Dummy00001 07.10.2014 14:33 # +1
strlen не знаю кому нужен.
мне lowercase & uppercase пригодился бы (почему и гуглил) что бы перетягивать (и унифицировать) переменные из разных частей системы, которые следуют разным соглашениям (типа $(includes) vs. $(INCLUDES)). я хотел просто проверку забомбить: если переменная не найдена, то попробовать ее имя в lowercase & uppercase, и только потом обламываться.
laMer007 07.10.2014 15:34 # 0
Сайлент попытки никогда ни к чему хорошему не приводили.
++++++++
$(iNcLuDeS)
Dummy00001 07.10.2014 15:54 # 0
там конфиги генерятся либо из шела, либо шелом из .c/.h файлов, и в последствии используются в нескольких местах, включая мэйкфайлы. то что изначально предназначено для enum'ов в С использует lowercase имена. для шелла - переменные окружения - uppercase.
мэйк это единственное место где это всё в одно место сливается, почему и выглядит кривовато.
я просто пытался избежать заводить еще один набор переменных (которые все еще раз переименовывают) и хотел просто "искать" нужные значения. добавление/удаления префикса/суффикса на мэйке не проблема - но смена регистра только через внешнюю комманду.
betking1 27.11.2014 16:22 # 0