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

autotools это вообще позор

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

К тому, что мне нужны модели, примеры. И порты кажутся более нужными для изучения чем portage

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

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

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

И претензии у тебя к ней.

Читать научить сначала. У меня претензии не к ней, а к portage. Суть претензий в том, что portage не make.

Суть в том, что все описанные тобой недостатки портажа в данном топике являются следствием работы make. И точно так же присутствуют в портах.

все описанные тобой недостатки портажа в данном топике являются следствием работы make.

Да нет же. Недостатки portage вытекают из выбранной его разработчиками технологии его реализации.

а в портах этого можно было бы избежать (возможно переписав их слегка).

Недостатки, на которые ты указал в этом топике, вызваны командой make. Точка. Чтобы от них избавиться, надо переписать команду make. Как в портах, так и в портаже.

Недостатки, на которые ты указал в этом топике, вызваны командой make. Точка.

эта фраза не имеет смысла (требует раскрытия/уточнения).

Недостатки portage, на которые я указал, не вызваны командой make. Если бы там была другая команда, например ant, недостатки portage сохранились бы в полном объёме.

Чтобы от них избавиться, надо переписать команду make

Чтобы избавиться от недостатков portage не надо переписывать make, надо переписывать portage (а 2*2=4)

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

use-флаги и cflags те же можно реализовать и на Makefile.

один ты меня понимаешь...

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

EnvVars которые чёта умеют или не умеют.

Я понял в чём дело. Ты прочёл не мой комментарий (сделав вывод из неправильного прочтения изошел на говно. и даже не извинился). При том что ничего не понимаешь в portage, например, не знаешь где там файлы с точками.

Тебе пояснить, почему твой вброс является толстым и глупым?

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

Есть основания полагать, что EnvVars в FreeBSD не умеют вот так

Есть подозрения полагать, что ты FreeBSD в глаза не видел.

у интеллектуалов тоже есть мнение про компьютерщиков

У графоманов, ты хотел сказать.

Есть подозрения полагать, что ты FreeBSD в глаза не видел.

ты намекаешь, что фрибздшные файлы с точкой могущественнее гентовых?

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

Разве колесо не лучше, чем машина?

Машина (bsd) на круглых колёсах (make) лучше, чем машина (portage) на квадратных (конкретная реализация portage)

Вы точно тот комментарий залинкали? И если да, вы фрибеседе видели вживую?

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

Более того, в фре есть юз-флаги.

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

Поздравляю ты сравнил зелёное и сладкое.

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

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

ты намекаешь, что фрибздшные файлы с точкой могущественнее гентовых?

Ты точно на тот комментарий ответил?

use-флаги и cflags те же можно реализовать и на Makefile.

Софт программами на C/C++ не ограничивается. И билдсистема бывает не единственная. USE-флаги - это, в общем случае, абстракция над конфигурационными опциями билдсистемам

Суть претензий в том, что portage не make.

portage — пакетный менеджер, который работает поверх make (и не только его). У него просто другая функциональность. Почему rpm-build не make? Почему dpkg-* не make? Почему pacman не make? Почему система портов в *bsd тоже не make? Почему <что угодно> не make?
Почему make не умеет много чего такого, что умеет portage? Да, можно наколхозить чего-то поверх make и получить... аналог portage, который будет не make.

Ты точно на тот комментарий ответил?

совершенно точно.

Как твои файлы с точкой связаны с USE-флагами?

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

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

Как твои файлы с точкой связаны с USE-флагами?

с какими юзе флагами?

> Есть основания полагать, что EnvVars в FreeBSD не умеют вот так
Есть подозрения полагать, что ты FreeBSD в глаза не видел.

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

Вы точно тот комментарий залинкали? И если да, вы фрибеседе видели вживую?

Я привел линк на то, что умеют USE-флаги.

FreeBSD я можно сказать не видел (точнее видел, но слишком мало для нормального понимания).

Поэтому те, кто видел FreeBSD, пускай сравнят makefile + EnvVars (которые они знают из своего опыта) с тем, что умеют USE флаги (что описано по моему линку).

Или это тема только для тех кто имеет нормальный опыт и в FreeBSD и в Gentoo? Боюсь таких очень немного.

Поэтому те, кто видел FreeBSD, пускай сравнят makefile + EnvVars

интересно, что это за вид наркомании такой, придумывать какие-то EnvVars, а потом строить фантазии на эту тему?

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

и

FOO=bar make all

и

make FOO=bar all

это разные вещи. в системе портов пользователи используют переменные мейка, которые задают либо в командой строке, либо в make.conf например.

аналогом того, что описано в потоке сознания про USE флаги, являются опции (OPTIONS). у пользователя есть возможность включать или выключать порт специфичные опции (например поддержку различных библиотек в mpv каком-нибудь), порт сам все правильно сконфигурит и добавит нужные зависимости.

раньше это настраивалось переменными мейка типа make -DWITH_SDL -DWITHOUT_ALSA т.п.), сейчас как правило это настраивается запуском make config, который показывает диалог настроек и генерирует файлик настроек для конкретного порта.

Ну в портах опенбсд wrapper'ы для всех популярных систем сборки есть, не понимаю, к чему ты привел эти аргументы... use-флаги — абстракция, да.

Ты так говоришь как будто есть принципиальная разница. Makefile == shell ебилдов, USE == OPTIONS (WITH), make == portage. Просто сделано на других технологиях.

В общем-то понятно почему сделано - когда появился портаж make во FreeBSD был довольно убог в плане фичей и тормознут, и ему напрашивалась замена для портов. С тех пор сменилось 2 или 3 поколения make'ов и теперь оно вполне пригодно. Portage тоже родился очень медленным и заметно ускорился с тех пор.

Я лично считаю что основная заметная разница (и она в пользу портов) - декларативный подход. Вместо того чтобы написать do_configure() { ./configure } в каждом ебилде, в портах есть поддержка фреймворка и достаточно написать GNU_CONFIGURE=yes, а оно уже под капотом сделает всё что нужно и как нужно - пропатчит кривые configure, доложит нужный файлов, установит окружение и вызовет таки configure с нужными аргументами. И если понадобится что-то дополнить, это будет сделано один раз и будет подхвачено всеми портами. Да, в portage есть аналоги, но только для самого основного. Во FreeBSD же всеми силами стараются никогда не писать императивный код целей руками.

Почему система портов в *bsd тоже не make?

Штой-та?

cd /usr/ports/www/firefox/ && make package-recursive - сделает в каталоге /usr/ports/packages/All/ бинарный пакет firefox-57.0.3.txz с зависимостями, готовые к установке в чистой системе.

Почему make не умеет много чего такого, что умеет portage?

Например?

Почему система портов в *bsd тоже не make?

Система портов *bsd make, неуч. Ты не разбираешься до такой степени что путаешь на чём написана система портов и сборочные системы апстрима.

Просто херню не надо нести, то, на что дана ссылка - это совсем базовые штуки :)

Жаль, что мы так и не увидели нормального сравнения Gentoo'шных USE флагов с аналогичными фичами FreeBSD...

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

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

Первая версия портаж была написана на шелл скрипте и была что-то около 300 строк.

откройте оффициальные доки и посмотрите. :)

Я не эксперт, iZEN надо кастовать. Фрей я уже несколько лет не пользуюсь: на ноутбуках оно смысла никакого не имеет.

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

• тебе нужно дать пользователю возможность скомпилять любой пакет, не заставляя пользователя читать какие именно флаги принимает *make файл и соответственно, разруливать за пользователя зависимости. ну т.е. пакетный менеджер.
  
• исторически сложилось, что при конфигурации информацию ты передаёшь, примерно, в виде --disable-foo --enable-foo и тут сложно понять, эти ваши foo включают\выключают автономные куски кода в пакете или теперь для компиляции нужны другие исходники из другого пакета.
  
• выходит, тебе нужно где-то сохранить эту информацию, неважно каким образом, главное знать, что делать если пользователь попросит disable. нужно собрать эту информацию, возможно руками, или ещё как.
• в процессе, вероятнее всего окажется, что disable-foo очень распространённый флаг, потому, что foo очень популярная штука, но пограмисты идиоты и иногда в их make файлах встречается --disable-fooze, что как бы одно и тоже, просто идиоты слишком верующие в макаронного монстра или слишком нетакиекаквсе
  
• может так случится, что тебе придёт в голову объединить все эти одинаковые сущности, иногда, под разными названиями, все эти fooze и foo в виде какой-то простой для пользователя штуки. например просто параметр foo, без disable\enable, ведь когда параметров много, зачем печатать одни и те же слова. осталось только придумать удобный семантический механизм для пользователя, как enable все эти флаги кучкой.
  
• в процессе работы, может быть ты начнёшь замечать, что все эти флаги конфигурации есть вариант объединить по ещё одному признаку, не только disable\enable, более абстрактному, например все foo и bar отлично объединяются общим признаком shit и теперь пользователь может заявить «я не хочу при компиляции ничего из shit» вместо перечисления foo и bar.

так в чём же отличие Gentoo'шных USE флагов и аналогичных фич FreeBSD?

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

Она (система) - есть! И эта CRUX.

Чётко сформулировано.

USE-флаги - это, в общем случае, абстракция над конфигурационными опциями

Но ТС тролль, так что...