с использованием уже установленного в системе Лиспа. Их может быть несколько, и в gentoo уже есть виртуальный пакет, поэтому естественно добавить в sbcl.ebuild следующее
bootstrap? ( virtual/commonlisp )
Однако первый кандидат для virtual/commonlisp и есть sbcl (это самая популярная имплементация), так что при попытке emerge sbcl происходит следующее: portage видит, что sbcl зависит от себя. Но он почему-то не может додуматься до простой попытки решения: раз зависимость проходит через virtual/commonlisp, попробовать выбрать следующий кандидат в виртуале, и круговая зависимость исчезнет.
Есть разные способы решить эту проблему, и есть гарантированно работающий: понадобавлять в sbcl USE-флагов, явно уточняющих, каким именно Лиспом компилировать.
Более правильным способом, впрочем, мне по ряду причин видится следующий: воспользоваться тем Лиспом, на который указывает eselect-lisp (его нет в gentoo, но неважно), а в самом eselect-lisp зафорсить eselect lisp update при его установке.
Беда в том, что в таком случае, если в системе нет ни одного Лиспа, emerge sbcl составляет следуюший список установки: eselect-lisp, clisp, sbcl. Здесь clisp это тот Лисп, которым предполагается компилировать. Но проьлема в том, что он в списке после eselect-lisp. Поэтому хотелось бы установить в sbcl.ebuild строгий порядок: сначала какой-нибудь Лисп, и только потом — eselect-lisp.
Я подозреваю, что в итоге насую в sbcl эксплицитных флагов. Но по-моему это существенно более грязное решение.
Поскольку в других пакетах уже используются флаги для явного указания компиляторов, в итоге я сделаю так и в своем случае (хотя это м.б. концептуально разные случаи). Но все равно остаюсь с выводом, что portage не обходит дерево решений полностью. Не вижу, кстати, почему virtual было бы неправильно использовать, т.к. эффект по-моему в точности тот же. Есть забавное псевдорешение: написать у eselect-lisp в зависимостях sbcl[-bootstrap], но это скорее всего приведет к неприятным последствиям потом.
Обсуждают сегодня