Arch Linux User Repository

My reasoning for ghdl vs ghdl-mcode is that ghdl configure defaults to mcode.

OK.

The python-pytooling dependency is a check dependency.

Maybe my explanation wasn't good enough.

As libghdl isn't needed by GHDL itself and libghdl being like GHDL but as a shared object file, pyTooling is only needed when building libghdl.so and then running the tests in testsuite/pyunit. Which makes only sense if your packages deploys libghdl.

Packaging GHDL could be simplified as follows:

• do not build libghdl (because not needed by ghdl itself). It also has no header file.
• remove pyTooling dependency
• do not run testsuite/pytest testcases, because these test the Python bindings using libghdl.

Somewhen later, if you like to provide a pyGHDL package, you could:

• build libghdl (unfortunately, there is no configure switch to disable building GHDL)
• require pyTooling as dependency
• run testsuite/pyunit as a standalone test

This is how I currently run the pipeline on GitHub.

But I hadn't noticed they didn't even link each other - that's... odd.

I know ... but that's how Tristan provides it today. I'm willing to support you and others, if maintainers create an issue at GHDL and request a structural change, so the GHDL executable becomes more like a frontend and all algorithms are inside of libghdl for shared usage (by the CLI frontende and by Python).

If there are any other patches or modification you need to have it easier in packaging, please report these too. I noticed Debian / APT applies patches as hell and there is no feedback to the orignal source. So if GHDL makes your maintainer life more complicated, please report it, and we check what we can do in ./configure or Makefile.in for Arch Linux.

• My reasoning for ghdl vs ghdl-mcode is that ghdl configure defaults to mcode. Also, as long as this package is in the AUR and users have to compile it, it is the one they should install to try out ghdl given the current state of packaging & ghdl.
• Thanks for the additional background info, that's all good to know for (near) future efforts.
• Package groups don't really make sense for conflicting packages - they also don't work on the AUR.
• All ghdl variants should be conflicting already, though I consider this to be less than ideal. I was planning to give building compatible packages a shot. Possibly something like what's done with java versions, possibly providing differently named binaries. idk yet.

The python-pytooling dependency is a check dependency. This means that you do not need it to install the package, but you do need it to build the package (albeit you can skip the test suite during makepkg with --nocheck).

I'll dig into what's possible with the current configure script some more before I have an opinion on ghdl/libghdl. But I hadn't noticed they didn't even link each other - that's... odd.

I haven't looked much into pyGHDL yet, but noted for the future.

Here are my hints:

• Arch should provide ghdl-mcode, ghdl-llvm and ghdl-llvm-jit
• ghdl-gcc can be obsoleted, because GCC backend will be dropped.
  The last missing feature (code coverage) was implemented in the mcode backend for 64 bit.
• LLVM-JIT is a new backend supporting LLVM compilation in-memory like mcode. (experimental)
• It looks like a package group /could/ be used to select which ghdl variant to install.
  https://wiki.archlinux.org/title/Meta_package_and_package_group
  Alternatively, a meta package could be used to refer to the preferred ghdl backend variant.
• All variants of ghdl should be marked as conflicting towards the other variants.

GHDL (mcode, llvm, llvm-jit, gcc) does not depend on python-pytooling nor python-pyghdl. GHDL itself as a binary doesn't need any Python.

The shared library (libghdl) created by GHDL is a standalone file, containing like 90% of the GHDL's executable. Please consider ghdl and libghdl two different products. In future, the ghdl executable /could/ be dependent on libghdl, but that's currently not the case.

For the usecase of Python (pyGHDL), I suggest this dependency chain:

• pyGHDL -> pyTooling
• pyGHDL -> libghdl -> (libgnat, libllvm if llvm backend)
• pyGHDL -> pyVHDLModel -> pyTooling

The best way to deploy pyghdl is a wheel file (or similar) that installs pyGHDL Python files, pyTooling + other Python dependencies and the so-file into site-packages. This also allows independent maintenance of pyGHDL and GHDL itself.

pyGHDL as a Python binding is tightly coupled to the shared object file.

I never considered your comment to be an attack. I was merely responding and disagreeing. There were never any hurt feeling involved ¯_(ツ)_/¯.

You were right to be confused, I should have referenced mcode. I'd originally set out to make a generic ghdl package, but then I found out that you cannot compile all ghdl backends together. So I then made it into a sane default but forgot to update the description.

On the conflicts part: I like the status quo. I think it makes more sense for other packages to declare conflicts (maybe someone would like to make a package that is not in conflict if that is even possible).

My comment was definitely not ment as an attack. I just spotted your package yesterday and was confused for a suprisingly long time about what backend this used and if ghdl-gcc was even relevant anymore. That is why I made the comment at all. Feel free to leave the name of the package as-is.

On the conflicts part: until yesterday you could install both ghdl and ghdl-gcc, and the first complaints would arrive very late (when Pacman tries to install some files owned by the other package). So ghdl and ghdl-gcc are definitely in conflict. I updated the conflicts array of ghdl-gcc to fix it, and looking at the example in https://wiki.archlinux.org/title/PKGBUILD#conflicts I am no longer sure if your package should conflict with ghdl or not. You could indeed argue that this is the default GHLD (Netbeans in the example), and ghdl-gcc is then like netbeans-cpp, and should provide ghdl and conflict with ghdl.

Anyhow, ghdl and ghdl-gcc are in conflict now as they should be.

I don't want to rename it since I expect this to be the basic first step for people just getting into ghdl (at least that's the situation that motivated me to re-create the package). If someone is having performance issues and needs a faster backend, I think at that point they'd be more than capable of looking around for the other ghdl packages. Otherwise, mcode is the most likely to work best in most configurations, if a bit slower than what is possible with ghdl.

Besides if you look at my PKGBUILD you'll see that it is as minimal as I could possibly make it. That is intentional.

That said, the description should have mentioned this was the mcode backend. My bad, that's fixed now.

Also, as long as this is called ghdl and not ghdl-mcode, I don't think it makes much sense to add a conflicts array, no? I could add a conflicts=('ghdl'), but that just seems weird.

For clarity you could consider calling this package "ghdl-mcode", following convention of other GHDL packages in the AUR. Also setting up the "conflicts" array could be nice.