Epic fail длиной 30 лет

Это не баг, это идейное топанье ножкой.

в любом коммерческом проекте такое считается багом

Опенсорс это настоящий коммунизм - никто ни перед кем не отвечает, так что кушайте что подают.

А в Microsoft'овском nmake эта проблема пофикшена? :^)

в любом коммерческом проекте такое считается багом.

МУХАХАХААХА, гхм, простите не удержался. Просто помню как народ совокуплялся с установкой какойто ide от borland (за кучи денег!), которая фейлилась с непонятной ошибкой, пока я не предложил ставить в каталог без пробелов.

В make пробел является разделителем элементов в списках, соответственно такое «исправление» поламает очень много всего. Где-то на их трекере предложение о возможном способе решения проблемы (может только частично), но его в действии, видимо, так и не проверили.

Сделали бы ключ дополнительный, регулирующий поведение.

какойто ide от borland (за кучи денег!), которая фейлилась с непонятной ошибкой

и где сейчас этот борланд

Epic fail длиной 30 лет

Да. Твоя жизнь.

Иногда мне кажется, что этот проект сопровождают дегенераты.

Ну так напиши свой или хотя бы сделай мега-форк make, ты ж у нас умняшка.

В винде половина софта не работает нормально с пробелами и не латиницей в путях.

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

И это коммерция на винде! где сотни лет пробелов и уникода.

Правильно, только 8.3 и ASCII

Как-то помнится, фиксил что-то в CMake-проекте, чтобы он собирался и ставился в путях, содержащих пробелы. Работало.

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

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

А можно просто не использовать полные пути:

all:
        gcc -o myprog myprog.c

Make — это набор костылей, который существует ради обратной совместимости. Или напомнить ещё о tabs vs. spaces?

она сохраняет до перезапуска

В смысле? Вешает систему при сохранении?

и где сейчас этот борланд

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

в любом коммерческом проекте такое считается багом

Ты пробовал обращаться к базе Оракл из программы, установленной в путь с круглыми скобками? Например, C:\Program files (x86)\ProgName\

Баг обнаружен на 64-битной Windows XP, но исправлен только в этом или прошлом году.

Или напомнить ещё о tabs vs. spaces?

А что в make с табами и пробелами?

и где сейчас этот борланд

Разного рода Delphi и C++ Builder'ы продолжают развиваться, но уже под крылом Embarcadero Technologies: https://ru.wikipedia.org/wiki/Embarcadero_Technologies .

В марте 2017-го года вышли Delphi 10.2 Tokyo и C++ Builder 10.2 Tokyo.

Если случайно в отступ попадёт пробел, то тебя ждёт закономерный FAIL

разупорись, до перезапуска игры сохранение есть, потом - нету

Make — это набор костылей, который существует ради обратной совместимости. Или напомнить ещё о tabs vs. spaces?

Удаки, сделавшие и поддерживающие этот make ещё совместимость там умудряются ломать, вообще (смех):

http://esxi.z-lab.me:666/~exl_lab/screens/Makefail.png

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

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

мне кажется, что этот проект сопровождают дегенераты

В сухом остатке: make — ещё один позор мира UNIX, постыдный, срамной и нерукопожатный.

разупорись, до перезапуска игры сохранение есть, потом - нету

Это как? При первом запуске есть, при последующих нету? Или после ребута снова появляется?

Make вообще неповоротлив и не портируем даже между собой.

Я бы вообще выбросил его на помойку истории.

Лучи согласия и всяческой поддержки этому господину.

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

К дегенератам, сопровождающим make, присоединяются дегенераты использующие пробелы в именах файлов, а так же non-ASCII-1 символы и хитрые знаки пунктуации.

Ссзб короче. Ни make, ни ненормальные имена файлов не нужны

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

Кстати да, в начале, да и середине нулевых, как мне кажется, многие гамесы страдали такой хренью. Вот взять тот же «Ил-2 Штурмовик». Уже в 2009 году я на форумах обнаружил кучи тем с одной проблемой: игра после установки не запускалась с непонятными ошибками. Оказалось всё просто: в пути не должно было быть отличных от базовой латиницы символов. Всякие мамкины геймеры же почему-то любили и в те славные времена создавать каталоги с кириллическими названиями типа: «Игры». И всё, потом плакались на форумах.
Ну и почему-то есть у меня привычка всегда в именах файлов и директорий заменять пробелы «нижним подчёркиванием». До сих пор. Откуда сие пошло вспомнить не могу, но причина должна была быть.

4.2.

В винде половина софта не работает нормально с пробелами и не латиницей в путях

ну не половина. А так что в линуксе, что в венде - примерно одинаково. Встречается иногда.

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

Убогенькая UNIX-консолька научила, где эти пробелы надо оббивать \ скорее всего. У самого такая привычка со временем выработалась.

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

https://ru.wikipedia.org/wiki/Delphi_for_PHP Ахаха.

нижним подчёркиванием

Покажи мне «верхнее» подчёркивание. Ну или хотя бы среднее. Именно подчёркивание, а не дефис, минус или тире

на него опираются CMake

Не мейком единым. CMake много что может использовать. Я лично предпочитаю Ninja.

На самом деле, сам по себе этот знак ничего не подчёркивает, так как на одно знакоместо на дисплее можно поместить только один символ, поэтому его иногда называют не «подчёркивание», а «андерскор» («Underscore»). Кроме того, этот символ часто называют «Нижнее подчёркивание», что некорректно и является плеоназмом — подчёркивание всегда выполняется снизу.

что некорректно и является плеоназмом — подчёркивание всегда выполняется снизу

Так я о том же

почему я первый раз про это слышу

покажи минимальный пример штоле

На него + meson стало модно переходить последнее время. За последнее несколько месяцев пару крупных проектов видел. ЕМНИП гном, Меса, системд.

Да, meson мне гораздо больше, чем clang, нравится. Хорошо, что крупные проекты на него переходят.

meson

Там хоть более-менее нормальный язык build-скрипта, в отличие от CMake. Наверное потому RedHat с ним и возится.

QBS ещё интересен, но развивается медленно и тащит много Qt-хлама.

А Gradle вообще JVM тянет :(

QBS ещё интересен, но развивается медленно и тащит много Qt-хлама.
А Gradle вообще JVM тянет :(

Питон не сильно лучше, но за отсутствием альтернатив, сойдёт.

хоть более-менее нормальный язык build-скрипта

Я во всей этой теме не разбираясь. Но слышал притензии что там не тьюринг полный язык.

винда это стандарт для разработки программ в линуксе? зачем повторять баги которые есть в ней?

Ну не дружит мейк с пробелами, да, ничего хорошего в том нет. Но:

1. Если используешь в путях файлов пробелы, то ссзб.

2. Лучше всё равно ничего нет.

всё равно ничего нет

Весь сценарий компиляции и сборки можно изложить на баше.

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

Покажи мне «верхнее» подчёркивание.

Ну всё, как я буду теперь жить дальше? Забыл я как правильно этот символ называеццо.

Так запили универсальную систему сборки с зависимостями и пакетами для любых интерпретаторов/компиляторов в чём проблема то?

Сам ты 4.2