Почему в FreeBSD хватает просто makefile-ов и EnvVars

потому что gentoo пошла по пути усложнения, use-флаги и cflags те же можно реализовать и на Makefile.

Разве make не лучше чем portage?

Нет.

зато гента популярнее

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

Есть основания полагать, что EnvVars в FreeBSD не умеют вот так: В чем преимущество USE-флагов перед опциями сборки? (комментарий)

Лучше на mk(1) и rc(1).

что такое EnvVars?

environment variables

что такое environment variables?

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

А то я бы взял javascript и jake

https://en.wikipedia.org/wiki/Environment_variable

что я должен прочесть по этой ссылке, чтобы понять «Почему в FreeBSD хватает просто makefile-ов и EnvVars»?

EnvVars в FreeBSD не умеют вот так

то что они не умеют это в FreeBSD это ни разу не показатель. Это конкретно у BSD недостаток.

Можно же сделать другой комплект соглашений, чтобы умели.

Эта ссылка должна разъяснить тебе, что такое environment variables.

понять «Почему в FreeBSD хватает просто makefile-ов и EnvVars»?

а что тут понимать? BSD-же живёт и никакой portage не нужен

мне пофигу на portage, и я знаю что такое environment variables.
мне интересно «Почему в FreeBSD хватает просто makefile-ов и EnvVars» и что такое EnvVars в этом контексте.

что такое EnvVars в этом контексте.

Мне было лень писать словосочетание environment variables и я его сократил в такую аббревиатуру.

Почему в FreeBSD просто хватает

потому что просто хватает. Пользователи BSD есть, и это наблюдаемый факт

ещё раз спрошу, что такое environment variables? судя по твоим ответам — это нечто волшебное чего просто хватает.
и даже возможно, это как-то связано с тем, что пользователи BSD есть.
будешь продолжать или всё-таки напишешь, какого чёрта переменные окружения стали фишкой фряхи и расскажешь как часто ты их используешь при компилянии портов, вместо использования конфигов которые парсятся трильярдом *.mk файлов?

какого чёрта переменные окружения стали фишкой фряхи

Я как раз удивлён тем, что переменные окружения совершенно одинаковые и в BSD и в linux, но при этом в BSD их хватает, а в linux их не хватает и нужны USE-флаги

будешь продолжать

да! Я так и продолжаю считать, что можно построить аналог portage исключительно средствами make

переменные окружения совершенно одинаковые и в BSD и в linux и в маке и в винде и в ректалосе и вообще везде где они существуют.
или ты считаешь, что написав в шелле OPTIONS_UNSET=DOCS, environment variables автомагически что-то делают?
или от тебя вообще кроме лозунгов про portage на любой вопрос ничего не добиться?

если не пытаться подъе...ать, то добиться можно. А так проблема с твоей стороны.

environment variables автомагически что-то делают?

а им это не нужно, потому что есть bash-команды внутри make-файла. Именно они что-то делают как при наличии, так и, самое главное, при отсутствии portage

Т.е. ты не использовал ни FreeBSD, ни Gentoo и пришёл сюда их сравнивать. Нуок.

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

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

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

ну да, и что?

внутри make-файлов в base фряхи нет bash-команд.

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

приходить без волшебных EnvVars которые чёта умеют или не умеют.

Я не утверждал, что у переменных окружения есть поведение.

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

Толстовато.

А я не хочу знать в чём различие.

Можно выкинуть питон и использовать вместо него шелловый скрипт? Очевидно можно.

Работает это как-то в BSD? Работает.

Значит Portage не нужен. (и даже вреден)

Можно выкинуть питон и использовать вместо него шелловый скрипт?

При сравнивых возможностях, будет медленнее и сложнее в поддержке.

Работает это как-то в BSD?

Далеко не всё имеющееся в портаже, есть во портах.

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

есть ли сопоставимые возможности в другом.

А меня не интересуют фактические возможности. Меня интересует стратегия. Правильно ли сделали, что создали portage или это была стратегическая ошибка. (потому что недостающие возможности можно и дописать)

Пока я считаю, что всё можно было сделать и без portage.

Между тем введение portage в тулчейн подавило некоторые возможности make (portage не умеет _только_ достраивать, он излишне брутален)

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

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

Правильно ли сделали, что создали portage или это была стратегическая ошибка

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

1. говно ли portage
2. использовать ли portage
3. есть ли возможность не использовать portage

у интеллектуалов тоже есть мнение про компьютерщиков:
http://samlib.ru/b/burxjak_a_w/digital_economy.shtml

Типичный хороший компьютерщик, даже занятый довольно сложной работой, — это весьма средний по умственным способностям человек, натаскавшийся в своей профессиональной области. Как правило, на интеллектуала он не тянет. Суждения типичного хорошего компьютерщика даже о сфере его профессиональной деятельности, как правило, ограничены и наивны. Он — придаток к сложным компьютерным системам. Он больше других подвержен всяким компьютерогенным зависимостям. Если у повара и врача их профессиональные знания — в основном о природном, не зависящем от мнений людей, то у компьютерщика — о преходящих условностях. Компьютерная литература, которой 15 лет, — это в основном мусор, причём не потому, что наука ушла вперёд. Чем больше в стране компьютерщиков, тем меньше реалистично мыслящих граждан, на которых можно опереться в больших делах и от которых будет польза в критических условиях. Компьютерщик окажется голодным ненужным никем, зато скорее всего с геморроем, вялой мускулатурой и привычкой к комфортному офисному существованию.

portage не умеет _только_ достраивать

Это вообще что значит?

Это означает, что даже с включенным FEATURES=«keep-sources» он всё равно повторно выполняет операции (типа копирования в неимоверных количествах). Многие из этиз операций можно было бы не выполнять и таким образом ускорить сборку

Какое отношение этот поток сознания обиженки от гуманитариев имеет к обсуждаемому вопросу о пакетных менеджерах в конкретных операционных системах?

у тебя ограниченный список вопросов которые ту можешь ставить:

у меня ещё есть бурная неуёмная фантазия, в отличие от тебя

1. говно ли portage

неважно

2. использовать ли portage

нет смысла, он тормозной

3. есть ли возможность не использовать portage

однозначно есть

повторно выполняет операции (типа копирования в неимоверных количествах)

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

Многие из этиз операций можно было бы не выполнять и таким образом ускорить сборку

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

Копирования чего и куда?

файлов с места на место. Сначала из архива во временную директорию, оттуда в установочную директорию, потом сама установка - тоже копирование

Теперь расскажи, как работает make при сборке.

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

И исходники берёт прямиком из архива, не распаковывая? А потом в процессе сборки не складывает бинарники во временную директорию, в которой потом не делает линковку и из которой потом не инсталлит бинарники в конечные пути на файловой системе?

И исходники берёт прямиком из архива, не распаковывая?

Вообще говоря мог бы, если бы через losetup смонтировал или тому-подобный фильтр-деархиватор

не складывает бинарники во временную директорию, в которой потом не делает линковку

Это несущественно, т.к. выполняется в любом случае

и из которой потом не инсталлит бинарники в конечные пути на файловой системе?

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

Но make ничего этого не делает(и это правильно, потому как писали его грамотные люди, а не ты). Сейчас для тебя это будет откровением, но непосредственно для сборки портаж вызывает всё тот же make(или аналоги - зависит от пакета). И все эти действия полностью аналогичны и в портах, и в портаже.

Но если бы make был сквозной и вычислял бы как внутренние зависимости пакета, так и внешние зависимости между пакетами - не пришлось бы выполнять принудительные операции, которые сейчас выполняются каждый раз, так как portage не имеет возможностей make по проверке состояния собранности (всякие там файлы с точками по фазам - это слёзы)

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

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

чтобы точки по фазам не пошли.

я имею в виду файлы

.compiled
.configured
.packaged
.prepared
.pretended
.setuped
.unpacked

Мне фиолетово что аналогично между portage и портами при фантазировании моей идеальной лучшей в мире системы

Именно. Потому как по сути являются одним и тем же. Упрощённо говоря, и то, и другое вызывает обёртку над configure && make && make install, предварительно проверив зависимости и передав в configure опции сборки.