LINUX.ORG.RU

Назовите хотя бы одну причину существования долбанного meson...

 , , , ,


0

6

Указываю новые CFLAGS, CXXFLAGS, запускаю meson setup --reconfigure с новым buildtype, запускаю ninja, И НИЧЕГО НЕ ПЕРЕСОБИРАЕТСЯ!!! Только линковка запускается повторно!
Для чего нужна билдсистема, которая не может отреагировать на изменение конфигурации? Чем это лучше мейкфайла или bash-скрипта? Чем это лучше autotools, который им заменяют в конце-то концов (другой синтаксис - субъективщина)? Что делал этот чёртов reconfigure, если не привёл к пересборке?

★★★★★
Ответ на: комментарий от watchcat382

не вижу я в твоём мейкфайле ничего крамольного. я про тот, который в pdf. мелкие несущественные ошибки есть, но они не помешают сборке.

там больше всяких определений для AVR'ки, чем самих сборочных деклараций.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

Я себе даже шпаргалку написал:

Ошибку libtool: You should recreate aclocal.m4 with macros from libtool 2.4.6
Правим так:
rm build/libtool.m4
cp /usr/lib/aclocal/libtool.m4 build
autoreconf -vfi

Вместо libtool.m4 может быть aclocal.m4 с подобной же ошибкой (копируем из /usr/share/libtool/aclocal.m4)
irton ★★★★★
()
Ответ на: комментарий от Iron_Bug

CMake … в принципе не работает с абсолютными путями. он замкнут в песочнице директории проекта и отчаянно не желает из неё вылезать.

То есть ты с CMake даже хеллоуврот не собирала, но мнение имеешь. Ещё один ”эксперт„ уровня @EXL.

anonymous
()
Ответ на: комментарий от anonymous

очень много собирала. и большие проекты по работе, в том числе. и там на эти грабли и наступали, тащемта. свои проекты я с ним не пишу.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

да ладно?

target_sources(${PROJECT_NAME} PRIVATE "${CMAKE_SOURCE_DIR}/../foo.c")

- работает

target_sources(${PROJECT_NAME} PRIVATE "/path/to/foo.c")

- работает

target_link_libraries(${PROJECT_NAME} PRIVATE "/path/to/foo.a")

- снова работает?

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

Lrrr ★★★★★
()
Ответ на: комментарий от Lrrr

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

если говнокодом называть cmake - то да, не работал именно говнокод. и не 20 лет назад, а значительно меньше.

впрочем, похрен на него. я с ним сейчас дел не имею, кроме мелких фиксов в сборке пакетов, и очень рада.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 2)
Ответ на: комментарий от watchcat382

Пробел точно такой же допустимый символ в имени файла как и любой другой.

Ограничения ФС известны: в имени не может быть слэша, так как это разделитель, и нулевого символа.

Не надо «практиками» оправдывать убогость языка.

wandrien ★★★
()
Ответ на: комментарий от Iron_Bug

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

Могут, но не обязаны. В крайнем случае я как пользователь 3rd party библиотеки могу сам написать команды для ее поиска.

но главный минус в том, что он в принципе не работает с абсолютными путями. он замкнут в песочнице директории проекта и отчаянно не желает из неё вылезать. а иногда позарез надо. и никак.

CMake может выполнять дейтсвия по абсолютным путям в том числе. Можешь подсказать, какую именно задачу работы с абсолютными путями не получилось решить с помощью CMake?

rumgot ★★★★★
()
Ответ на: комментарий от wandrien

из-за этих ваших пробелов в путях, в комстроке незаменимых программулек придется путь в кавычках писать, ибо непонятно, где кончается путь, и где начинаются опции или еще что. а поскольку «-» в путях особых умников - это есть завсегда, то от пути с пробелами и тире и опций с тире любой парсер в ступор впадет.

alysnix ★★★
()
Ответ на: комментарий от Iron_Bug

Может быть, но как на зло больше таких проектов не попадалось

irton ★★★★★
()
Ответ на: комментарий от rumgot

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

я стараюсь использовать просто Makefile'ы. самое простое и минималистичное решение для большинства задач. если что-то сложное, тогда автотулзы.

Iron_Bug ★★★★★
()
Ответ на: комментарий от watchcat382

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

Верно. Пример, который ты привёл, это пример плохого мейкфайла, и в последующих версиях мануала его переписали.

лучше было бы формировать список объектников из списка исходников
Я и пытался всего лишь добиться ответа на логичный вопрос «почему?».

Потому что это лишнее звено, если оно нигде больше не участвует.

Вот как переменные OBJ1, OBJ2, OBJ3 в том мейкфайле - лишние и не нужны. Они являются информационным мусором, захламляющим понимание логики работы make’а. Точно так же переменная с исходниками, которые используются только для преобразования в переменную с объектными файлами, - это лишний шаг и посторонний информационный шум, загрязняющий мейкфайл.

Хороший мейкфайл - максимально простой мейкфайл. Язык make достаточно выразителен, чтобы не было необходимости лепить бесполезные промежуточные шаги.

LamerOk ★★★★★
()
Ответ на: комментарий от wandrien

полно, на самом деле. я много собираю пакеты для софта. процентов так 10-15 пакетов в тарболлах не содержат .ac и .am. а некоторые даже умудряются в репозитории их не выкладывать. то есть их совсем нет в доступе. редко, но пару раз сталкивалась с таким.

ну и вот месон ещё. пошла нездоровая мода уничтожать нормальные конфиги и внедрять ни с чем не совместимые и зависимые от версий сраного месона. причём ладно бы оставили при этом Makefile или автотулы, так нет - выпиливают! этим страдает фридесктоп особенно. по-моему, именно от них эта зараза начала распространяться по сорцам. но вроде как в моём случае проблема уже решилась в этом треде, хотя и не полностью. замена тулзов этого кривого поделия на сишную реализацию не меняет её зависимость от версии. а автотулзы от версии практически не зависят, как и Makefile'ы, например.

ещё есть отдельная мода брать версию из скриптов гита при сборке. только вот в тарболлах гита нет и получаются нули. приходится это патчить. тоже немало таких.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 3)
Ответ на: комментарий от Iron_Bug

Мне сразу cmake тоже казался слишком громоздким. Однако у нас на проекте многие сложные задачи он выполняет. А для простых проектов там получиться короче чем на Makefile-ах делать.

rumgot ★★★★★
()

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

ya-betmen ★★★★★
()
Ответ на: комментарий от Puzan

redo всем замечательно. Правда неюзабельно, но какая разница, мы же все равно ничего им не собираем, да?))

Lrrr ★★★★★
()
Ответ на: комментарий от Iron_Bug

в предутренних сумерках открыть это было как удар в нос :)

Аналогичные ощущения от ярко-белого фона. Я думал что я один такой с сильной непереносимостью белого фона. Я хотел свой текстовый вариант того же самого выложить но хостинг временных файлов 0х0.st стал ругаться на неправильный user agent. А куда еще положить без регистрации и смс я сходу не нашел.

погляжу на досуге, что там «неправильно».

Буду премного благодарен если прокомментируете «неправильность».

watchcat382
()
Ответ на: комментарий от wandrien

Пробел точно такой же допустимый символ в имени файла

Если пробел и другие не рекомендуемые для имен идентификаторов символы технически возможно запихать в имя файла то это не значит что такое нужно делать,создавая неудобства другим людям и провоцируя глюки. Есть классическая рекомендация по именованию идентификаторов и ее рекомендуется придерживаться.

А знаете ли вы что микрософтовский сишный компилятор технически позволяет пихать русские буквы в имена функций и переменных? Немецкие тоже. Но большинство адекватных людей старается этого не делать. Вот и с именами файлов желательно поступать также если эти файлы могу быть переданы куда-то за пределы вашего личного домашнего компа. Это просто что-то вроде правил хорошего тона.

watchcat382
()
Ответ на: комментарий от watchcat382

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

я колупаюсь с кодом в основном ночью. я вообще «сова» и не любитель жары. а летом ночью не так жарко и серверу ночью легче: я заметила, что температура железа ночью градусов на 10 ниже, в среднем. видимо, днём там активно работают другие серверы и вообще днём жарче. а сегодня у нас тут день - не день, а какая-то серая мгла. так что дома темно даже днём. и в этой темноте достаточно совсем лёгкой подстветки, чтобы видеть текст достаточно хорошо.

из «неправильности» я там только видела дублированное удаление obj файлов. остальное в порядке, я бы трогать не стала. я про мейкфайл в pdf, если что. который WinAVR.

Iron_Bug ★★★★★
()
Ответ на: комментарий от watchcat382

а ссылку на какой-то rus-linux я открыла, увидела там баннеры с мордой одного пи..., чуть не блеванула и сразу это закрыла. я могу вырезать баннеры, чтобы их не видеть. но ресурсы, которые постят у себя такое, я просто не хочу посещать. это вызывает глубокое отвращение. не знаю, кем надо быть, чтобы до такого опуститься.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 1)
Ответ на: комментарий от LamerOk

это лишний шаг и посторонний информационный шум, загрязняющий мейкфайл.

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

Согласен,что это лежит в области личных предпочтений. По всей видимости мои предпочтения совпадают с личными предпочтениями авторов многих мэйкфайлов где список исходников есть и помещается где-то ближе к началу,в отдельной переменной чтото типа SRC.

это пример плохого мейкфайла

Если пример плохого мэйкфайла мог написать сам Столлман то что уж говорить о ничтожных недопрограммистах микроконтроллеров avr :) Более интересно было бы обсудить чем из современных сборочных средств можно было бы заменить вот такие мэйкфайлы для небольших проектов - что столлмановский пример,что тот который для avr. Или нынешние сборочные системы расчитаны на огромные проекты размером с какой-нибудь хром и для подобной мелочи будут излишне монстрообразны?

watchcat382
()
Ответ на: комментарий от dataman

Только что проверил с https://github.com/Calinou/0x0

Только что проверил с этим же скриптом - User agent not allowed. Это оно на curl ругается.

А сам curl у меня вот такой:

$ curl --version
curl 7.88.1 (i686-pc-linux-gnu) libcurl/7.88.1 OpenSSL/1.1.1w zlib/1.2.11 brotli/1.0.9 zstd/1.4.8 libidn2/2.3.0 libpsl/0.21.0 (+libidn2/2.3.0) libssh2/1.9.0 nghttp2/1.43.0 librtmp/2.3 OpenLDAP/2.4.59
Release-Date: 2023-02-20, security patched: 7.88.1-10+deb12u6~bpo11+1
Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL threadsafe TLS-SRP UnixSockets zstd

watchcat382
()
Ответ на: комментарий от wandrien

Это не убогость языка. Это trade-off. Ты принимаешь ограничения, но в то же время получаешь удобство в реализации и использовании языка сборки. При этом практика показывает, что эти ограничения не приносят каких-то существенных неудобств.

К примеру в подавляющем большинстве ЯП нельзя создавать идентификаторы с пробелами. Это такой же trade-off. Имя файла это такой же идентификатор.

vbr ★★★★★
()
Ответ на: комментарий от watchcat382

Если пример плохого мэйкфайла мог написать сам Столлман

Столлман ни в одном месте не является "безошибочным" "техническим гением". Он буквально ВУЗовский препод, программирующий в свободное время.

По всей видимости мои предпочтения совпадают с личными предпочтениями авторов многих мэйкфайлов

Как я уже говорил выше, с вероятностью в 0,9(9) это не "личные предпочтения", а фундаментальное непонимание механизма работы мейка и попытки писать на нём как скрипт на шелл.

Возможно вы сторонник экстремального минимализма

Экспертная система искуственного интеллекта на базе обратного вывода (чем и является make) к минимализму имеет весьма отдалённое отношение.

чем из современных сборочных средств можно было бы заменить вот такие мэйкфайлы для небольших проектов

Для небольших проектов вообще никакие "сборочные системы" не нужны - обычный build.sh соберёт проект быстрее, чем пользователь отпустит клавишу, запустившую процесс сборки.

LamerOk ★★★★★
()
Ответ на: комментарий от LamerOk

Как бы ты написал простой мейкфайл, который собирает проект в двух конфигурациях: debug и release. Проект состоит из одного main.c файла (ну для простоты, держим в уме, что их потенциально может быть много), для debug должен использоваться флаг -Og, для release должен использоваться флаг -O2. При этом команды make debug && make release должны работать адекватно, т.е. не собирать якобы релизный бинарник из дебажных объектных файлов.

vbr ★★★★★
()
Последнее исправление: vbr (всего исправлений: 1)
Ответ на: комментарий от Iron_Bug

Про сидение в темноте и «совиность» полностью согласен с вами. За комментарий по мэйкфайлу для avr - спасибо. Он кстати хотя и писался исходно для winavr,но есть его адаптированный к линуксу вариант с совсем минимальными отличиями,им и пользуюсь.

watchcat382
()
Ответ на: комментарий от vbr

У любого инструмента есть ограничения применения, у мейка - это построение решений на базе состояния файловой системы.

Либо надо делать две разные цели хотя бы в разных директориях сборки, либо выносить сборочные флаги в отдельный файл (что, с учётом их влияния на результат операций, само по себе не плохая идея).

LamerOk ★★★★★
()
Ответ на: комментарий от Iron_Bug

какой-то rus-linux я открыла, увидела там баннеры с мордой

У меня uBlock Origin стоит поэтому баннеры я почти никогда не вижу. Несколько лет назад удалось хорошо подобрать версию этого блокировщика к версии браузера vivaldi - да так и работает. Извините если незамеченным мной баннером оскорбил ваше эстетическое чувство.

watchcat382
()
Ответ на: комментарий от watchcat382

для AVR'ок, в общем-то разницы почти нет. многие поддерживает gcc и можно целиком на опенсорце разрабатывать прошивки. с FPGA такой роскоши нет. хотелось бы поковыряться, но там кругом проприетарщина.

Iron_Bug ★★★★★
()
Ответ на: комментарий от watchcat382

у меня сейчас браузер не хромиум и там расширений практически нет. блокировщик рекламу режет, можно свои правила добавлять. но ресурсы мордора он по дефолту не режет. поэтому я увидела на сайте мерзость и его сразу закрыла. дело не в том, что я могу её вырезать. а в том, что владельцы сервера _это_ туда засунули. и это ниже плинтуса. я не дружу с людьми, у которых такие «наши партнёры».

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

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 2)
Ответ на: комментарий от LamerOk

Экспертная система искуственного интеллекта на базе обратного вывода (чем и является make)

Впервые вижу такое мнение что make относится к экспертным системам и искусственному интеллекту. Я,увы, не настолько силен в теоретических вопросах программирования чтобы как-то это прокомментировать.

Для небольших проектов вообще никакие «сборочные системы» не нужны - обычный build.sh

Вполне может быть что вы и правы. Тем не менее мэйкфайлы в микроконтроллерных проектах,небольших по определению, регулярно встречаются. Надо будет поискать пример достаточно продвинутого build.sh,чтобы был столь же удобен в обращении как этот мэйкфайл.

watchcat382
()
Ответ на: комментарий от vbr

простой мейкфайл, который собирает проект в двух конфигурациях: debug и release.

Кстати, для микроконтроллеров оно актуально. Потому что с включенной оптимизацией компилятор начинает распихивать «короткоживущие» переменные по регистрам и потом симулятор-отладчик vmlab не может их показывать так как у них нет адресов в памяти.

watchcat382
()
Ответ на: комментарий от LamerOk

Экспертная система искуственного интеллекта на базе обратного вывода (чем и является make) к минимализму имеет весьма отдалённое отношение.

вот только не надо эту грязь с бредогенераторами примазывать к make. make - это нормальный софт, а не какое-то там хипстерское «ИИ» на говнпистоне.

Iron_Bug ★★★★★
()
Ответ на: комментарий от vbr

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

с FPGA такой роскоши нет. хотелось бы поковыряться, но там кругом проприетарщина.

Согласен,что FPGA штука интересная, но придумать для них осмысленное применение в домашне-радиолюбительских условиях я что-то затрудняюсь.

Вот что бы мне хотелось попробовать - это попрограммировать МК на Ada. Но avr-ada хотя и существует но сильно недоделана,да и сильно урезана из-за ограничений самих avr. Зато нашел пример попытки запустить Аду на STM32F103C8T6: http://www.hrrzi.com/2017/11/ada-on-2-ebay-bluepill-board.html Зимой когда будет много свободного времени попытаюсь этот эксперимент повторить,тем более что такой МК у меня есть в наличии.

watchcat382
()
Ответ на: комментарий от LamerOk

Вот у меня с этим проблемы.

Либо пишем

debug: build/debug/app

release: build/release/app

build/debug/app: build/debug/main.o
  $(CC) ...

build/debug/%.o: src/%.c
  $(CC) ...

build/release/app: build/release/main.o
  $(CC) ...

build/release/%.o: src/%.c
  $(CC) ...

Т.е. дублируем правила для каждой конфигурации. Чтобы не дублировать - придётся делать генерацию кусков через eval/call. В общем это уже не простой makefile получается.

Либо пишем

app: build/$(target)/app

build/$(target)/app: build/$(target)/main.o
  $(CC) ...

build/$(target)/%.o: src/%.c
  $(CC) ...

и вызываем через make target=debug app. Вроде относительно просто, но вызывать неудобно, автодополнение не работает (в первом случае zsh как-то умеет парсить Makefile и выдаёт автодополнение, к чему я уже привык) и вообще как-то странновато это всё выглядит…

vbr ★★★★★
()
Последнее исправление: vbr (всего исправлений: 1)
Ответ на: комментарий от watchcat382

хотя вроде, емнип, у Xylinx были какие-то опенсорцные тулзы. но я могу ошибаться. и плат с Xylinx у меня нет. у меня есть альтеры, потому что тестовые платы мы на них делали и они у меня остались с прошлой жизни. но Альтера жадная и там вся среда для разработки проприетарная. Xylinx проще альтеры, но не будешь же BGA для PCIe плат паять дома на коленке :)

мне была бы очень интересна какая-нибудь PCIe плата с FPGAшками, под которые можно собирать, симулировать и прошивать прошивки с опенсорцными тулзами. но это, наверное, несбыточные мечты.

Iron_Bug ★★★★★
()
Последнее исправление: Iron_Bug (всего исправлений: 4)
Ответ на: комментарий от alysnix

Если вызывать программульку не через shell, такой проблемы не будет т.к аргументы передадутся как есть в argv. Впрочем, не знаю, будет ли это корректно работать в winapi, где аргументы непрерыаной строкой прилетают, но там есть как встроенная функция разбивки на аргументы, так и костыли для путей с пробелами, вероятно всё и так заэкранируется под капотом

mittorn ★★★★★
() автор топика
Ответ на: комментарий от watchcat382

Уже любой современный компилятор разрешает. Один умник заюзал греческую дельту в исходниках

mittorn ★★★★★
() автор топика
Ответ на: комментарий от mittorn

и это зря, имхо. идиотов в мире много. они ведь понапишут. впрочем, что понапишут идиоты, это неважно. нормальный софт люди пишут в UTF-8, в английской кодировке и никто туда никаие странные локали не втаскивает. это негласный регламент нормального кода.

Iron_Bug ★★★★★
()
Ограничение на отправку комментариев: