[Pkg-electronics-devel] Packaging GHDL yosys plugin

[dxld at darkboxed.org]

Hi Andreas,

how are things going?

GHDL 2.0.0 is out which has all the necesarry enablement and fixes for the
ghdl-yosys-plugin. I've rebased my packaging branch on your over here
https://salsa.debian.org/electronics-team/ghdl/ghdl/-/merge_requests/3/commits.

I've also forwarded the essence of our modify-install-paths patch
upstream[1] since they managed to break some paths again in 2.0.0 ;)

[1]: https://github.com/ghdl/ghdl/pull/1996

I also saw your autopkgtest enablement work and submitted an upstream issue
about the testsuite not working in-tree here:
https://github.com/ghdl/ghdl/issues/1997.

My branch still has the naive libghdl enablement but you can cherry pick
the other commits if you're not ready for that yet.

--Daniel

On Tue, Jan 18, 2022 at 10:16:54PM +0100, dxld at darkboxed.org wrote:
> Hi Andreas,
> 
> On Tue, Jan 18, 2022 at 10:01:15PM +0100, Andreas Bombe wrote:
> > Sorry, haven't gotten around to looking at it more before.
> 
> No worries, I've been busy getting yosys/nexpnr and its dependencies
> updated anyway so you're not blocking anything -- yet ;)
> 
> > I don't like static linking and that is also discouraged in Debian.
> > Interestingly the VPI library is statically linked, but when creating a
> > module it gets dynamically linked in (with RPATH). Anyway, that module
> > has to be loaded by running ghdl with the right options, it doesn't
> > really get used standalone.
> > 
> > That's why I felt it was okay to install an unversioned library into a
> > package internal directory. It so happens that gcc and llvm built
> > simulations can be run directly, but the official way is to run it
> > through the ghdl executable. So there is really no expectation that
> > those binaries can be installed permanently or would be compatible
> > between ghdl versions.
> 
> That's fair yeah. Unless upstream provides us with proper soname versioning
> for vpi I don't think it's worth splitting this out either.
> 
> > Back to libghdl however: I had a quick look into the ghdl docker image,
> > which would be sort of an official binary build of upstream ghdl. There
> > the installed libghdl looks to have a somewhat reasonable SONAME and if
> > upstream keeps versioning that reasonably with future changes we could
> > go with that.
> > 
> > And as long as that library is fully independent and does not itself
> > call the ghdl binaries. I'm not sure what interactions that could have
> > and having to soname version the regular ghdl packages is not feasible.
> 
> I don't think it does call ghdl. I just did an strace run with a typical
> use of the yosys ghdl plugin and I don't see any exec* syscalls at all.
> 
> > Anyway, in the near future I wanted to enable automated testing in the
> > ghdl package. Updating to a git snapshot and adding the libghdl (and the
> > Python packages, also depending on libghdl) could come afterwards.
> 
> Let me know if/how I can help with that. I've been wanting to look more
> into autopkgtest and such anyway.
> 
> --Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-electronics-devel/attachments/20220308/5039ceb8/attachment.sig>