Add VHDL release packaging

[kraigher]

In summary this still needs to be done;

• Build vhdl_parser as packaged
• Publish github release on v.*.*.* tag
• Use release notes from release_notes/v*.*.*.md file

[umarcor]

Currently, it is not straighforward to publish releases assets/artifacts from multiple GitHub Actions jobs (there is not official releaser as in other services). However, I believe that Rust has built-in cross-compilation (as golang), doesn't it? If so, implementing the release should be easy.

Regarding the VSCode extension, ghdl's ls and docker can be used as an example to build and distribute a VSIX file.

About docker images. On the one hand, the VSIX can be distributed in it, to allow users to attach to the container with VSCode's 'Remote - Containers' extension. On the other hand, the registry to be used needs to be discussed. GitHub Package Registry is built-in, and no separate credentials need to be managed, but it is not public: a GitHub token is required to access the images. hub.docker.com is public: anyone can docker pull without a token.

[Xcodo]

I started looking at this in March when I was looking to get my team using Rust HDL with VSCode on our Xilinx FPGA projects on Windows. Then I had a baby and everything got shelved!

I resurected my fork and CI build last night and this morning - take a look:
GitHub - https://github.com/Xcodo/rust_hdl
TravisCI - https://travis-ci.org/Xcodo/rust_hdl

Currently the Windows build fail (new issue for that coming), but the build from before I merged the last eight month's changed (build 13) worked, so I think the cross-compilation configuration is good.

P.S. This is my first look at Rust, so I may be doing it wrong!

[Xcodo]

I guess the best way would be to add a bash script or two that are called in the Travis YAML, rather than adding lots to the YAML script section. We might also need to build for all the environments within the same build rather than using the Travis matrix option to be able to do a single push to GitHub.

Happy to have my fork used as a playground for CI stuff, I can add other owners if someone else picks up the work adding the libraries or pushing releases to GitHub. I'm not going to be able to do much more for a few weeks.

[kraigher]

@Xcodo good that you are already on it. Congratulation to your baby!

[Xcodo]

I now have the CI on my fork producing build artifacts. You can see the latest build here for this branch.

Two things that I wanted to check your prefered approach @kraigher.

Artifact naming

Currently the artifacts are named after the Rust target architectures.
vhdl_ls-x86_64-pc-windows-gnu
vhdl_ls-x86_64-unknown-linux-gnu
vhdl_parser-x86_64-pc-windows-gnu
vhdl_parser-x86_64-unknown-linux-gnu
Should they be simplified just to -windows and -linux?

Folder layout

Currently the folder layout isn't as above. Firstly the top level folder in the repo is vhdl_libraries so I used that rather than lib, secondly I kept the GHDL library folder names when I copied them in and thirdly vhdl_ls.toml is in the libraries folder rather than at the top level. It's easy to change to be how you want.

vhdl_ls-x86_64-pc-windows-gnu/
--bin/
----vhdl_ls.exe
--vhdl_libraries/
----ieee2008/
------fixed_float_types.vhdl
------fixed_generic_pkg-body.vhdl
------...
----std/
------env-body.vhdl
------env.vhdl
------textio-body.vhdl
------textio.vhdl
----vhdl_ls.toml

Release tag format

Next I'll be adding the release process for tags. What format of tag do you want to use (Semver?). Do you want to just set-up the release so that a changelog can be added manually? Or we could immediately publish pre-release tags (with suffixes like v1.0.1-alpha) and prepare release builds for manual publishing.

[kraigher]

Nice work!

1. I am ok with the artifact naming as it currently is. It does not need to be simplified.
2. Regarding folder layout I think your proposed structure works fine. It is just that standard libraries should not and can not be taken from GHDL as they contain GHDL builtin special handling. I have my own standard libraries as you can see on master.
3. Regarding release tags I prefer semver. I think making actually making a release requires some kind of manual step where a release notes/changelog is updated. But ideally it should be as simple as updating a release notes document and push it together with a new tag.

[Xcodo]

Sorry I misunderstood your gitter comment about the libraries. Fixed now.

[kraigher]

@Xcodo

I refactored the configuration loading to make it easy to add loading of installed configuration: See: https://github.com/kraigher/rust_hdl/blob/master/vhdl_parser/src/config.rs#L236-L239
You only need to add a load_installed_config there to implement it.

I think we should use the cfg! macro or attribute to set the relative path to the installed vhdl_ls.toml file. By default it think the relative path should assume the binary ends up in target/release such that when building locally with cargo build --release during development it will just work without having to create the installed folder structure.

When building for release we can set a --cfg clag to rustc (https://doc.rust-lang.org/rustc/command-line-arguments.html#--cfg-configure-the-compilation-environment) such that the relative path is according to the install folder format.

Could you do this? It involves a small bit of rust coding. If you do not feel up to it I can do the final steps.

[kraigher]

I think the only thing remaining on this is to actually publish the release to GitHub upon pushing a tag with syntax v*..

[kraigher]

I think we can maintain a folder for release-notes/v*.*.*.md that can be used as the change text for the github release. Then the release procedure would be to add such an .md file and then make a release commit with a v...* tag.

[kraigher]

Also the vhdl_parser binary needs to be packaged just like vhdl_ls as it also references the standard libraries.