Выпуск Fortran Package Manager (fpm) 0.9.0

Данный пакетный менеджер создавался по образу пакетного менеджера Cargo языка Rust.

Вчера увидел https://github.com/poac-dev/poac :)

Poac (pronounced as /pəʊək/) is a package manager and build system for C++ users, inspired by Cargo for Rust.

Да-да. Но общая тенденция меня немного пугает.

Было забавно пытаться опакетить fpm менеджер, который пытается скачать свои зависимости из интернета для сборки в изолированной среде sandbox для portage. Пришлось сначала опакетить их, а потом пропатчить .toml-файл проекта fpm, чтобы он линковался с динамическими библиотеками, а не пытался собирать статические в подпроектах. Хорошо, что он поддерживал эти средства управления зависимостями.

Есть ещё в некоторой степени похожий проект - FoBiS, там тоже автоматически определяются связи между файлами и последовательность сборки. Но без реестра пакетов

Наверное, стоит добавить ссылку на исходники (Фортран и немного Си): https://github.com/fortran-lang/fpm

Но без реестра пакетов

Мне Cargo только этим и нравится. :)
$ cargo search ... часто бывает полезен не только для Раста.

https://github.com/jordansissel/fpm

Нейминг это сложно.

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

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

Тут больше система сборки, а идея автоматического скачивания меня тоже не очень радует, тем более, что на HPC кластерах всё равно доступа «наружу» нет обычно.

Ну вот, а кто-то мне тут недавно распылялся, что фортран мертв и не нужен.

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

100% программ на Go тянет «пакеты» напрямую с GitHub…

идея автоматического скачивания

Мне кажется, что с развитием интернетов мир вообще свернул куда-то не туда. Сборка программ тянет все из инета, браузер выполняет какой-то хренпойми какой код на JS без всяких проверок разрешений и автора, программы сливают все в сеть (и хорошо еще если просто стаистику использования и нажатия кнопок, а не конфиденциальную инфу о юзере)…

А можно сделать один пм для всех язычков?

portage

Чем оно лучше npm?

А можно сделать одного бога для всех язычников?

Вот тебе и ответ.

Любопытно, надо будет потыкать.

мне нравится Си, где всё ручками

Что ручками? Скачивается исходный код из тех же источников?

посмотрел на список библиотек. NAG library в списке не нашел. Не удивился :)

Мнда... Когда в фортране появились константы и перезача параметров по значению, я сказал «ОК, наконец-то»!

Когда в фортране повились if/endif/do/enddo я терпел. Иногда пользую.

Когда в фортаре появились структуры и из него убрали equivalence и арифметический if я выматерлся и подумал, что «вот, блин, докатились»... :)

Когда в фортране появился свободный синтаксис, я подумал, «ну ладно, наконец-то у людей перфокарты кончились» :)

Когда в фортране появился интерфейс с языком C, я сказал «ну и хорошо» и писал коннекторы в C++ и корбу.

Но вот этого я уже выдержать не могу!! — https://github.com/wavebitscientific/functional-fortran

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

еще бы и систему сборки унифицировали и вообще заживем. НО нет

FORTRAN живее всех живых ;)

Так NAG library - коммерческая ж библиотека.

Да, с момента выхода FORTRAN IV, Fortran уже не тот.

НО нет

Это ненадолго. Скоро OpenAI вам всем покажет как надо.

Вот потому и не удивился, что ее нет в списке. :) Я вообще не понимаю, накой этот менеджер пакетов нужен. Ни по способу запуска, ни по способу линковки компилятор фортрана ничем не отличается от компилятора С. И способ установки библиотек для С, имеющийся в системе, обычно всех устраивает. А этот-то нахрена?

В C совсем не умею, как быть если нужно 2 разные версии библиотек?

«Package managers? In C we write everything ourselves!» :D

https://www.youtube.com/watch?v=s7wLYzRJt3s

Не знаю, но пишут его люди в общем-то активно пишущие на фортран на работе, судя по по всему.

Насколько понял, основная проблема существующих систем сборки - построение иерархии зависимостей модулей. Видимо, определение того, что от чего зависит не всегда хорошо работает. И им помимо этого захотелось автоматом зависимости подтягивать.

Профессор Фортран умер, но дело его живёт!

_Не_нужно_. Всего, что есть в /usr/lib обычно хватает.

Странная идея. Интерфейсов обычно хватает. Да и сколько тех библиотек? Ну NAG, ну MKL... Ну OpenMP. Распараллеливание на потоки автоматом подтягивается (у Интела, во всяком случае). А тут... Ну выдал тебе линкер сколько-то unresolved external'ов, ну и чо? С С/С++-же зависимости разруливаются системами сборки, коих в избытке.

Я-то полагал, что фортранисты — люди старой закалки, им все эти пищалки и перделки не нужны от слова «совсем».

Вообще-то уже давно есть https://github.com/clibs/clib. ;)

Естественно, просто не юзай язычковые недоПМ, а юзай системный.

Намекаешь, что просто надо было объявить свой ПМ триединым и поплыть насаждать его миру с оружием?

Завтра иду на собес по фортрану 🫣

Кокаин найух сдох! Героин возвращается, причем самым ойухенным образом!

И че почем и как, если не секрет?

Да вот не похоже. Видать, здоровье у людей уже не то, что б белый пользовать в тех же дозах. Им чего полегче захотелось. Или на кислого потянуло :)

Изначально fpm был реализован на haskell, потом переписали на fortran.

Помимо этого участники этого сообщества занимаются разработкой stdlib. Ещё иногда не хватает библиотек и интерфейсов для парсинга параметров командной строки, toml, json, работы со строками, тестирования.

С С/С++-же зависимости разруливаются системами сборки, коих в избытке

Тот же meson и cmake поддерживают сборку модулей для C++ только для MSVC.

Это у нас фортранисты старой закалки и 50 COMMON блоков на файл не предел ;)

что на HPC кластерах всё равно доступа «наружу» нет обычно.

В этом случае Meson мне в целом понравился. Ищет зависимости в системе, если нет, то можно сказать как собрать, если очень надо, то можно подготовить для offline сборки (заранее скачать нужное одной командой).

При чём мне удалось запустить hello_world на GTK под windows, когда meson скачал и скомпилировал все зависимости (😜 meson compile и у тебя GTK под виндой).

По сабжу: Meson поддерживает fortran + OpenMP, MPI, Coarrays.

Вот только логичность и user friendly это не про него.

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

meson compile и у тебя GTK под виндой

Горячие финские парни...

Интересно, а можно ли подружить Meson с GTK 2…

Системный :) Все остальное от лукавого или для локальных установок.

Удачи! Хоть кто-то делом занимается!

Ага, примерно про это. А пилить новое или легаси поддерживать?

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

Изначально fpm был реализован на haskell, потом переписали на fortran.

Это хорошо, что я в момент прочтения этого прочно сидел на стуле... :)

Ну ниччо, так, эклектичненько.

Это у нас фортранисты старой закалки и 50 COMMON блоков на файл не предел ;)

Да посмотреть, как тот же NAG написан, так не только. Хотя там культура выше явно. Все интерфейсы в стеле 90го фортрана вылизаны... Сейчас, по крайней мере. То, что на торрентах лежит, так семьдесят-седьмой семьдесят-седьмым :)

После того, как собрал Кеды под FreeBSD — все можно :)

Интересно, а можно ли подружить Meson с GTK 2…

Под онтопиком через интерфейс pkg-config нормально работает. Т.е. в meson-файле пишем gtk2_dep = dependency('gtk+-2.0') и в путь.

Под винду вероятно проще будет создать wrap-файлы на бинарные сборки.

Return of the Living Dead: FORTRAN to the Grave (2005) смотрите на всех экранах этой страны вместо новой русалочки. 16+

Самый известный fpm это несомненно пхп, а не все эти штуки. И появился он раньше.

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

Не одному.

Скачивание сомнительного кода из сомнительных источников - зачем?

Это тут ни при чём. Пакетный менеджер может и несомнительный код качать.

А идея убогая потому что от неё несёт языковым фанатизмом. Какая разница на каком языке пакеты? Проект может состоять из частей на разных языках вообще, а зависимости желательно прописывать единообразно и в одном месте. В нормальных ОС уже есть пакетные менеджеры, и незачем изобретать что-то ещё.