Вы уверены, что стоит все символы из .cmt файлов добавлять в Requires? При сборке Why3 из-за этого туда попадает 169 внутренних "интерфейсов" и порождающие анметы, которые не устранить. Например, в Fedora в их ocamldeps .cmt не парсятся: https://github.com/rpm-software-management/rpm/blob/master/scripts/ocamldeps.sh Пока я попробовал сделать так, чтоб не отключать autoreq ocaml полностью: %add_ocaml_req_skip ?cmt_requires.* Но, он явно для этого не был предназначен.
К сожалению да, уверен. Без них многие зависимости между всеми devel пакетами ocaml автоматически не вычисляются и приходится делать много ручной работы. req_skip для такого случая нормальное явление.
При следующем обновлении ocaml сделаю ещё один заход на его зависимости, посмотрю можно ли что-то с этим сделать. Вся проблема в том, что апстрим не предполагает разделение пакетов на devel и runtime части и если всё паковать в один пакет - то без cmt зависимостей всё находится. Если разбивать, то приходится часть сборочных зависимостей добавлять вручную и они становятся несоответствующими перечисленным в opam файле. Но так было во времена ocaml 4.14 - с новым 5.3 я не проверял, возможно ситуация улучшилась.
1. Если дело только в связи devel и runtime, то в чем проблема подхода с `Requires: ocaml-%name = %EVR` в ocaml-%name-devel? Решать лишние зависимости сложнее чем прописать эту строку. 2. Проблема в %add_ocaml_req_skip в том что добавлять туда 169 интерфейсов придется вручную, что сложно (их список можно определить только читая лог сборочницы) и некрасиво. 3. Проблема предложенного костыля с %add_ocaml_req_skip что при тюнинге RE он сломается. 4. Хотел еще предложить абстрактную идею, может стоит усовершенствовать `ocamlobjinfo -format-reqprov`, раз это наш код, чтоб он не выводил локальные интерфейсы. ocamlobjinfo -shape показывает кое какую информацию по которой можно предположить локальность интерфейса. builder@x86_64:~/tmp/why3-buildroot$ ocamlobjinfo -shape ./usr/lib64/ocaml/why3/why3.cmt | grep Stdlib__Arg f8e8890965c203c25968b7219e7d0d37 Stdlib__Arg builder@x86_64:~/tmp/why3-buildroot$ builder@x86_64:~/tmp/why3-buildroot$ ocamlobjinfo -shape ./usr/lib64/ocaml/why3/why3.cmt | grep Why3printer 3ead4b7364cdbdd1a793c713d8894f4c Why3printer "Why3printer"[module] -> CU Why3printer; 5. Если локальные интерфейсы надо выводить, то надо их выводить и в Provides, разве это не баг autoreq?
Если нужна только авто-зависимость между devel пакетами может парсить META, там же есть builder@x86_64:~/tmp/why3-buildroot/usr/lib64/ocaml/why3$ grep req META requires = "menhirLib re unix zarith dynlink zip sexplib"
(In reply to Vitaly Chikunov from comment #3) > 1. Если дело только в связи devel и runtime, то в чем проблема подхода с > `Requires: ocaml-%name = %EVR` в ocaml-%name-devel? Решать лишние > зависимости сложнее чем прописать эту строку. Нет, проблема не в связи devel и runtime, а в связи devel одного пакета с devel других пакетов. > > 2. Проблема в %add_ocaml_req_skip в том что добавлять туда 169 интерфейсов > придется вручную, что сложно (их список можно определить только читая лог > сборочницы) и некрасиво. Согласен. > > 3. Проблема предложенного костыля с %add_ocaml_req_skip что при тюнинге RE > он сломается. > > 4. Хотел еще предложить абстрактную идею, может стоит усовершенствовать > `ocamlobjinfo -format-reqprov`, раз это наш код, чтоб он не выводил > локальные интерфейсы. ocamlobjinfo -shape показывает кое какую информацию по > которой можно предположить локальность интерфейса. Сейчас это не наш код - это модифицированный апстримный код, а модификация только меняет формат вывода, не делая больше ничего в плане логики. > > builder@x86_64:~/tmp/why3-buildroot$ ocamlobjinfo -shape > ./usr/lib64/ocaml/why3/why3.cmt | grep Stdlib__Arg > f8e8890965c203c25968b7219e7d0d37 Stdlib__Arg > builder@x86_64:~/tmp/why3-buildroot$ > builder@x86_64:~/tmp/why3-buildroot$ ocamlobjinfo -shape > ./usr/lib64/ocaml/why3/why3.cmt | grep Why3printer > 3ead4b7364cdbdd1a793c713d8894f4c Why3printer > "Why3printer"[module] -> CU Why3printer; > > 5. Если локальные интерфейсы надо выводить, то надо их выводить и в > Provides, разве это не баг autoreq? Это опять же проблема апстримного кода. У локальных интерфейсов точно есть реализация ? Такое ощущение что это та же ошибка: https://github.com/ocaml/ocaml/issues/9050
(In reply to Vitaly Chikunov from comment #4) > Если нужна только авто-зависимость между devel пакетами может парсить META, > там же есть > > builder@x86_64:~/tmp/why3-buildroot/usr/lib64/ocaml/why3$ grep req META > requires = "menhirLib re unix zarith dynlink zip sexplib" тогда, видимо, надо все META перенести в devel. И ещё есть несколько пакетов, в которых META отстутсвуют (начиная с самого ocaml). На самом деле, конечно, гораздо интереснее вместо META парсить dune - но ещё остались пакеты, собираемые через findlib и dune есть в меньшем объёме чем META.
Переоткрою что бы не потерять и не забыть что надо сделать. 1) META точно надо перенести в devel 2) надо посмотреть, получится ли в runtime пакете оставить только cmxs и cma (первая рантайм для бинарей, вторая для байткода). Сейчас из cmxs вообще не выгребаются зависимости. Этот код надо ещё добавить в ocamlobjinfo 3) это изменение желательно делать при выходе новой версии ocaml (когда пересобираются все пакеты), что бы не было конфликтов между devel и runtime пакетами разных сборок.
Сделал ещё один подход. В devel пакете остаются: -regex '.*\\\.(a|o|cmi|cmt|cmti|cmx|cmxa|ml|mli|exe)$' \\\ В runtime: -regex '.*\\\.(cmo|cma|cmxs|so|js)$' \\\ зависимости вида cmx забираю из cmxs зависимости вида cmi - из cma Интерфейсы должны быть в runtime части, т.к. Dynlink их использует при динамической подгрузке библиотек. если я зависимости вида cmt убираю, то автоматического определения зависимостей между devel пакетами не остаётся. Для why3 предлагаю просто удалить cmt файлы. По идее они не обязательны для работы, если why3 их как-то специально не использует.
перенёс META в devel пакет, перенёс весь байткод в runtime пакет. Отключил cmt/cmti. Там, где есть нативная компиляция - зависимости считаются прекрасно. На i586 кроме как cmt/cmti брать зависимости неоткуда (если считать их по хешам символов): /usr/lib/ocaml/csexp/META /usr/lib/ocaml/csexp/csexp.cmt /usr/lib/ocaml/csexp/csexp.cmti /usr/lib/ocaml/csexp/csexp.ml /usr/lib/ocaml/csexp/csexp.mli /usr/lib/ocaml/csexp/dune-package /usr/lib/ocaml/csexp/opam dune-package еть не везде - много где на dune не перешли и переходить принципиально отказываются. там же нет и opam. META есть почти везде. Видимо других вариантов, кроме как генерация зависимостей из META пока нет.
