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

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

Press F to Fortran

Да даже и в не нормальных есть. Homebrew же.

Я на федоре часто ванильное ставлю, потом лень удалять. Пока в один прекрасный момент больше не бутится.

Интересно можно узнать какие патчи сует Федора в ваниль?

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

Кстати, а есть ли в принципе компилируемый язык со стабильным ABI(ну или относительно стабильным), кроме Си, крестов, фортрана и паскаля?

Я так понимаю, что всякий язык, понимаемый GCC (в смысле compiler collection), опирается на его ABI. То есть, еще ADA и ObjecttiveC. На обоих языках кода под Linux я не видел от слова совсем. Коллега мой когда-то в прошлом веке писал на Аде для VAXa, с тех пор новостей про этот язык я не слышал. ObjC — это коллеги за углом, но у них теперь есть модный Сфифт :) Ну вот еще Пролог и Лисп можно вспомнить из условно живых, но у них не ABI, там же машинного кода нет, там ниже исполняющая система.

А вот, Ocaml, кстати, не требует тащить пять компиляторов и восемь рантаймов.

Тут не в ABI дело, основной бардак проистекает от неустоявшейся исполняющей системы. У того же Хаскеля добавление фич означает изменения в рантайме. Вот и придумывают всякие ghcup.

Таких много: pacman, apt, yum, dnf, portage, nix и тд. Выбирай на свой вкус.

На фортране конечно легаси. Новое на C++. Но то легаси особо попирать не собираются.

Да они же все делают одно и тоже

апт не умеет ставить в отдельный каталог, вроде как.

Даешь cobol package manager!

Ну так не юзай убогий apt =D

На обоих языках кода под Linux я не видел от слова совсем.

with Ada.Text_IO; use Ada.Text_IO;
procedure Hello is
begin
   Put_Line ("Hello LOR!");
end Hello;

$ gnat make hello.adb
$ stat hello

File: hello
Size: 30912

Попробуй nix, для разработки как раз самое самое. На десктопе применимость крайне сомнительна, а вот для разработки - вполне.

А теперь что-нибудь более содержательное и с unchecked_conversion пжалста! :)

это чо можно использовать вместо Intel Fortran Compiler иле нет

Нет, компилятор таки понадобится, но зависимости между файлами проекта оно разрулит.

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

Странный ход мысли. Ручками ты же также «скачиваешь сомнительный код из сомнительных источников» и добавляешь в свою сишечку, только вручную. Более того, вручную ты можешь скачать из еще более сомнительных источников. Современные языки не обязывают тебя использовать пакетные менеджеры. Если у тебя такая сильная паранойя, то все еще можешь добавить пакет вручную, скачав его из источника, который тебе кажется не сомнительным.

autotools же ? самая унифицированная.

Чаще симейк с месоном встречал, честно говоря, так что нет

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

Бери выше! Даёшь Assembler Package Manager!

В нормальных ОС уже есть пакетные менеджеры, и незачем изобретать что-то ещё.

К сожалению, любимые нами классически опекеченные зависимости, непротиворечивые и недублирующиеся, rpm-спеки и прочие ебилды нынче не в моде: системный менеджер если и зовут, то чтобы поставить условные build-essential, curl, unzip и virtualenv в свежем контейнере, а дальше уже сплошные curl ... | bash и pip install во все поля, to name a few. Неудивительно, что народ разучился в пакеты с этими докерами, запечёнными зависимостями, жестко прибитыми версиями и статической линковкой.

Легаси - это всё, что поддерживается больше года?

https://github.com/Beliavsky/Fortran-code-on-GitHub

И поэтому компиляция проектов на C/C++ это всегда гребанная лотерея (я тут пробовал собирать эмуляторы для современных консолей из исходников и это тот еще зоопарк). Вместо того, чтобы набрать одну-две стандартных команд, как в Maven/Gradle для Java, нужно бегать с высунутым языком и качать самому исходники, править CMake и заниматься какой-то ерундой, которую можно было легко автоматизировать и стандартизировать, если бы был вменяемый пакетный менеджер.

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

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

Для начала стандартную макробиблиотеку хотя бы, ala SYSMAC.SML из RT-11

иногда смотрят и

вносят баги :)

Само по себе разнообразие библиотек неплохо. Плохо когда каждая из них уж слишком узко направлена: библиотека для удаления пробела, библиотека для перевода в нижний регистр, библиотека для перевода в верхний регистр, библиотека для замены «-» на «_», библиотека для сложения двух целых чисел и т.д.

Ну не без этого. И еще нерабочий код коммитят :)

Ещё интерактивный компилятор есть – lfortran, но там много чего ещё не реализовано.

интерактивный компилятор

Это интерпретатор, что ли?

P.S. Хотя нет, я прошёл по ссылке, там таки компилятор в LLVM. Тогда интересно, в чём заключается «интерактивность». :)

Он и компилировать может и его можно использовать, по словам авторов, как интерпритатор, в том числе для Jupiter Notebook.

По крайней мере, если его просто запустить, то запустится консоль как для python.

Рад за тех, кто 66 лет ждал и дождался!

Собственно, -dev/-devel пакеты в apt/yum

Особенно в этом плане питон доставляет,когда пакету нужны модули,которых нет в репах. Ставишь их такой pip’ом, и забываешь, а потом у тебя в дистре решают их опакетить. И начинается веселье…

Дождался чего?

Хе-хе, при этом pip list выводит список всех site-packages пакетов, как системных, так и пользовательских. Чтобы узнать что именно установлено пользователем, приходится лезть в пользовательских каталог site-packages и смотреть там.

А ninja-python (сторонний проект в виде wrapper) создан так, что тащит с собой свой ninja и опакетить его как wrapper поверх системного непросто, из-за того, как он устроен.

Когда у меня такое было, я просто поставил пакману ключ --overwrite '*' и не заморачивался.

что на нём пишется

Хотя бы сабж для удовлетворения собственных потребностей в сборке своих же программ.

Спасибо, потыкаю на досуге!

И cygwin

Пакетного менеджера для либ Фортрана.

Поэтому pip рекомендует не использовать себя из под root’а.

Ну вот да,там и без этого неразберихи хватает.