You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'd like to propose Nix for a more sophisticated library system, there are a couple of benefits:
It's already written, and is very sophisticated.
It can also capture non-Bluespec dependencies, should some simulation need some other software
It has support for Linux and MacOS
It supports per-project packages
Bluespec is already packaged for it (and was perhaps one of the first package managers to have it packaged?)
It supports pre-compiled packages so that you can ship compiled libraries.
This is more to gauge interest/opinions, I can do the Nix bits. In the end I'd imagine it to look something like this:
You could install global packages, e.g. nix-env -i bsc-contrib
You can have per-project packages, with Nix these are described by a shell.nix file, e.g.
# Imports default package set, optional argument,# can be overridden from the command line{nixpkgs ? import<nixpkgs>{}}:
withnixpkgs;# Use the default package set namespacemkShell{buildInputs=# A list of the project dependencies[bluespec# The already packaged bluespec compilerbsc-contrib# This repo# others...# Or to prevent it 'polluting' the lib/Libraries path, replace the above with(bluespec.withPackages[bsc-contrib])];}
There is one limitation of the BlueSpec compiler that I'm aware of, which is that it doesn't support either a nested namespace, or *.bo files pointing to their own dependencies, which means that essentially we have to have a flat path containing all the libraries a project uses (recursively), and this limits will lead to namespace clashes.
E.g. suppose a project has a file MagicNumbers.bsv (as an example), this means that no other dependency can have a MagicNumbers.bsv file.
This would need to be changed in the compiler.
The text was updated successfully, but these errors were encountered:
Hi,
I'd like to propose Nix for a more sophisticated library system, there are a couple of benefits:
This is more to gauge interest/opinions, I can do the Nix bits. In the end I'd imagine it to look something like this:
nix-env -i bsc-contrib
shell.nix
file, e.g.As an example, see https://gist.github.com/KoviRobi/1381abdfce8e87139e4d04cfef3d76be#file-example-bluespec-shell-nix-L16-L27 where the highlighted lines are an 'inline package'. Then we merge the libraries from the BlueSpec compiler and this repo with
symlinkJoin
. This is just a quick test, that I am using to play around with the connectal library.There is one limitation of the BlueSpec compiler that I'm aware of, which is that it doesn't support either a nested namespace, or *.bo files pointing to their own dependencies, which means that essentially we have to have a flat path containing all the libraries a project uses (recursively), and this limits will lead to namespace clashes.
E.g. suppose a project has a file
MagicNumbers.bsv
(as an example), this means that no other dependency can have aMagicNumbers.bsv
file.This would need to be changed in the compiler.
The text was updated successfully, but these errors were encountered: