1.2, Аноним (-), 11:33, 06/10/2014 [ответить] [﹢﹢﹢] [ · · · ]
| –12 +/– |
> добавлены новые переменные $(MAKE_TERMOUT) и $(MAKE_TERMERR), позволяющие переопределить потоки вывода сообщений и информации об ошибках вместо stdout и stderr.
Вот за что не люблю проекты конкретно от фонда GNU, так это за подобную монструозность. Когда откровенные недоработки в каком-то другом месте затыкаются подобными костылями. И эти люди потом ещё что-то говорят о качестве open source, хотя сами прилагают немало усилий по "исправлению" ситуации. Тьфу.
| |
|
|
3.18, Имя (?), 19:49, 06/10/2014 [^] [^^] [^^^] [ответить]
| –7 +/– |
Это неправда. Всё, что open source — free software, и наоборот. Вопрос в подходе к определению термина.
| |
|
4.19, Andrey Mitrofanov (?), 19:59, 06/10/2014 [^] [^^] [^^^] [ответить]
| +/– |
> Это неправда. Всё, что open source
Разница в убеждениях и действиях авторов.
> — free software, и наоборот. Вопрос в подходе к определению термина.
Не юли! Или "Всё и наоборот", или "вопрос". А то ишь ты, подстраховался он, болтунишка.
| |
|
5.20, Имя (?), 23:40, 06/10/2014 [^] [^^] [^^^] [ответить]
| –3 +/– |
>> Это неправда. Всё, что open source
> Разница в убеждениях и действиях авторов.
Нет.
>> — free software, и наоборот. Вопрос в подходе к определению термина.
> Не юли! Или "Всё и наоборот", или "вопрос". А то ишь ты,
> подстраховался он, болтунишка.
Никто не юлит. Несмотря на то, что определения технически разные, к результатам они приходят идентичным. Потому что определяют одно и то же, но через разные понятия.
| |
5.26, Аноним (-), 19:03, 07/10/2014 [^] [^^] [^^^] [ответить]
| +2 +/– |
>А то ишь ты, подстраховался он, болтунишка.
Наверняка он бздунишка. Это для них безразницы free и open.
| |
|
|
|
|
3.27, Аноним (-), 18:14, 08/10/2014 [^] [^^] [^^^] [ответить]
| +/– |
Для мелких проектов разницы практически не будет. На маленьком проекте что угодно для сборки будет подходить, хоть GNU make, хоть bmake, хоть вообще SCons. И, как говорится, на здоровье... А вот когда половишь баги GNU make на сборке исходников общим чистым весом за двадцать метров, начинаешь по-другому на неё смотреть.
| |
|
2.13, ананим (?), 17:15, 06/10/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> добавлены новые переменные $(MAKE_TERMOUT) и $(MAKE_TERMERR), позволяющие переопределить потоки вывода сообщений и информации об ошибках вместо stdout и stderr.
> Вот за что не люблю проекты конкретно от фонда GNU, так это за подобную монструозность. Когда откровенные недоработки в каком-то другом месте затыкаются подобными костылями.
И в каком месте тут недоработка, костыли и "монструозность"?
Сдаётся что ты, мил-человек, казачОк.
(Ты вообще хоть понял про что тут написано?)
| |
|
3.28, Аноним (-), 18:18, 08/10/2014 [^] [^^] [^^^] [ответить]
| +/– |
>>> добавлены новые переменные $(MAKE_TERMOUT) и $(MAKE_TERMERR), позволяющие переопределить потоки вывода сообщений и информации об ошибках вместо stdout и stderr.
>> Вот за что не люблю проекты конкретно от фонда GNU, так это за подобную монструозность. Когда откровенные недоработки в каком-то другом месте затыкаются подобными костылями.
> И в каком месте тут недоработка, костыли и "монструозность"?
> Сдаётся что ты, мил-человек, казачОк.
> (Ты вообще хоть понял про что тут написано?)
Для начала попробуйте сами подумать, ЗАЧЕМ может это понадобиться? Я не вижу ни одной вменяемой причины. Хотя стараюсь, честно. Не дураки же, по идее, пишут.
С другой стороны: вот обычный процесс, про него заранее известно, что он шлёт рабочий выхлоп в stdout, а всё остальное - в stderr. На это можно (было) полагаться, с этим можно (было) надёжно работать. А теперь, если я хочу работать - надёжно - с GNU make, то мне надо ещё и две новые переменные окружения контроллировать?!
| |
|
|
1.12, Kodir (ok), 17:02, 06/10/2014 [ответить] [﹢﹢﹢] [ · · · ]
| –4 +/– |
> ...переопределить потоки вывода сообщений и информации об ошибках вместо stdout и stderr
Мне кажется или это прямое нарушение UNIX way? Зачем тогда хвалиться на каждом углу со своими дурацкими pipes, если ЛЮБОЕ приложение вот так на ровном месте нагадит в цепочку перенаправлений?!
| |
|
2.14, Stax (ok), 17:15, 06/10/2014 [^] [^^] [^^^] [ответить]
| +/– |
Ну так это же *GNU* make, а GNU это Not UNIX :) Так что претензии по UNIX way'ности не принимаются!
| |
|
3.16, ананим (?), 17:31, 06/10/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
Претензии к вашему преподавателю информатики разве что.
И то, при условии что вы в принципе обучаемый.
Зыж
Для дЭбилов повторяю — командная строка имеет бОльший приоритет, чем переменные окружения, которые в свою очередь имеют бОльший приоритет, чем переменные конфигурационного файла.
Собственно именно поэтому пайпы В ПРИНЦИПЕ и возможны.
Например,
MAKE_TERMOUT=/dev/null make ....
переопределит переменную $(MAKE_TERMOUT) в мэйкфайле.
В общем,.. где вас вообще выращивают? В застенках каких проприетарных контор, раз вы так глупо наезжаете на опен-сорс? Две недели курсов и "спец" готов?
Вот жеж дэбилы.
| |
|
4.22, Посторонним В (?), 23:48, 06/10/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
>[оверквотинг удален]
> Для дЭбилов повторяю - командная строка имеет бОльший приоритет, чем переменные окружения,
> которые в свою очередь имеют бОльший приоритет, чем переменные конфигурационного файла.
> Собственно именно поэтому пайпы В ПРИНЦИПЕ и возможны.
> Например,
> MAKE_TERMOUT=/dev/null make ....
> переопределит переменную $(MAKE_TERMOUT) в мэйкфайле.
> В общем,.. где вас вообще выращивают? В застенках каких проприетарных контор, раз
> вы так глупо наезжаете на опен-сорс? Две недели курсов и "спец"
> готов?
> Вот жеж дэбилы.
Вы может быть лучше повторите зачем нужно MAKE_TERMOUT... Когда стандартный поток вывода...
| |
|
5.25, ананим (?), 12:30, 07/10/2014 [^] [^^] [^^^] [ответить]
| +/– |
Повторяю, (см. сабж) для определения потока вывода сообщений.
При этом неучи о пайпах могут не беспокоится, с ними всё будет по прежнему.
| |
|
4.23, Stax (ok), 23:54, 06/10/2014 [^] [^^] [^^^] [ответить]
| +/– |
Я прямо даже теряюсь. Преподаватель информатики? Застенки проприетарных контор? Наезжаем на опен-сорс? Пайпы возможны? Вот жеж вас понесло от маленькой шутки. Что же, буду продолжать стараться :)
| |
|
5.24, ананим (?), 12:24, 07/10/2014 [^] [^^] [^^^] [ответить]
| +/– |
В каждой шутке есть доля... шутки.
При этом очевидно, что с таким невежеством стараться вам особо не нужно. :D
| |
|
|
|
2.15, ананим (?), 17:22, 06/10/2014 [^] [^^] [^^^] [ответить]
| +/– |
От недостатка знаний такое бывает.
И не то ещё померещиться может неразвитому уму.
Зыж
Тебе не пох куда именно (на экран, в файл,.. в анб) приложение выводило поток для дескрипторов 1 и 2, если ты их в командной строке всё равно переопределяешь?
| |
2.17, Ordu (ok), 17:47, 06/10/2014 [^] [^^] [^^^] [ответить]
| +/– |
Вы поздно спохватились. В *nix изначально была возможность для приложения закрыть STDIN_FILENO, STDOUT_FILENO, STDERR_FILENO и открыть другие файлы с теми же файловыми дескрипторами. Прямое нарушение UNIX-Way присутствовало на этом UNIX-Way с самого начала.
| |
|
3.21, Посторонним В (?), 23:41, 06/10/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Вы поздно спохватились. В *nix изначально была возможность для приложения закрыть STDIN_FILENO,
> STDOUT_FILENO, STDERR_FILENO и открыть другие файлы с теми же файловыми дескрипторами.
> Прямое нарушение UNIX-Way присутствовало на этом UNIX-Way с самого начала.
Оно не нарушение. Оно - возможность. Одна из очень многих...
| |
|
|
|