<div dir="ltr">In my opinion, it's unlikely that normal users switch versions very often.<br>Many users will only install a single backend variant of GHDL.<br><br>Only a few user roles will switch them. One role is the GHDL enthusiast,<br>but he will eitherways compile GHDL from sources and install multiple<br>versions in parallel. The other role is regression testing, but this is usually<br>involving CI servers and Docker images for clean separation and cleanup.<br><br>I would prefer the reduced startup overhead to achieve good performance.<br><br>If this can't be decided, can the deb-file ask what to do? Like script based<div>switching or using alternatives? Also, this is only relevant when a second<br>GHDL variant gets installed. Not sure if deb files can handle this scenario </div><div>and check.<br><br>For the exit code:<br>I suggest moving it into the reserved range of Bash so 128 .. 255. Maybe a<br>250.<br><br>Kind regards<div> Patrick</div></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">Am Fr., 17. Apr. 2026 um 21:49 Uhr schrieb Petter Reinholdtsen <<a href="mailto:pere@hungry.com">pere@hungry.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">[Paebbels 2026-04-18]<br>
> Why don't you use alternatives to switch between variants?<br>
> Wasn't it created exactly for that usecase?<br>
> <br>
> Is there really an overwhelming usecase of constantly switching GHDL<br>
> backende and even operating multiple backends in parallel (for regular<br>
> users), which justifies such a performance penalty?<br>
<br>
Note, I am just a drive by debian developer interested in GHDL, so do<br>
not take my comments as gospel. I thus can not explain what the<br>
author of the wrapper script thought at the time, but I can look at<br>
the git history of the script (git log -- debian/ghdl.wrapper):<br>
<br>
commit f43ae0f8a56c012a7da57fc8c7408f58de7c26e1<br>
Author: Nicolas Boulenguez <<a href="mailto:nicolas@debian.org" target="_blank">nicolas@debian.org</a>><br>
Date: Wed Dec 14 13:48:00 2022 +0100<br>
<br>
Install the usr/bin/ghdl wrapper with dh_install directly<br>
<br>
commit d42537bf8a64365a874446e8772fd74bf094c90f<br>
Author: Andreas Bombe <<a href="mailto:aeb@debian.org" target="_blank">aeb@debian.org</a>><br>
Date: Wed Jul 24 18:10:20 2024 +0900<br>
<br>
Revert back to debian/3.0.0+dfsg2-1<br>
<br>
Restore a clean state as reverting individual commits in the series<br>
creates massive conflicts that would take too long to resolve.<br>
<br>
commit 201a83a5188db826793604066f7b3461128b3899<br>
Author: Nicolas Boulenguez <<a href="mailto:nicolas@debian.org" target="_blank">nicolas@debian.org</a>><br>
Date: Wed Dec 14 13:48:00 2022 +0100<br>
<br>
Install the usr/bin/ghdl wrapper with dh_install directly<br>
<br>
commit e8833d4e1ef4688eda68322d889e6acf3d244712<br>
Author: Jonathan McDowell <<a href="mailto:noodles@earth.li" target="_blank">noodles@earth.li</a>><br>
Date: Mon Apr 6 11:30:06 2020 +0100<br>
<br>
Update wrapper for newer releases. Thanks to Pavel Pisa (Closes: #930890)<br>
<br>
commit 895f335df5736ea1714b576f1811831cfd045116<br>
Author: Andreas Bombe <<a href="mailto:aeb@debian.org" target="_blank">aeb@debian.org</a>><br>
Date: Sat Aug 4 00:56:39 2018 +0800<br>
<br>
Change error message in ghdl wrapper<br>
<br>
Make the error message in case no ghdl executable is found less<br>
ambiguous and confusing.<br>
<br>
commit 6d3a3dfe2af4d94162f0c921611b16832b8fdde2<br>
Author: Andreas Bombe <<a href="mailto:aeb@debian.org" target="_blank">aeb@debian.org</a>><br>
Date: Sun Jan 14 20:53:34 2018 +0100<br>
<br>
New Debianization of ghdl<br>
<br>
The referred <URL: <a href="https://bugs.debian.org/930890" rel="noreferrer" target="_blank">https://bugs.debian.org/930890</a> > is a confusing<br>
read, but apparently the wrapper script interact with the build in<br>
interesting ways too. The commits do not explain why the alternative<br>
system was not used, or if it was considered.<br>
<br>
I'm not quite sure what to make of this, but suspect the decisions<br>
were made by people no longer active with ghdl, and thus no-one around<br>
can answer your questions. I do not know ghdl enough to know how<br>
often it make sense to be able for a user to change backend. Using<br>
the alternative system would place the decision in the hands of those<br>
with root access, while using the environment variable allow each<br>
non-root user to decide for themselves which backend to use. I guess<br>
that might make sense i an multiuser setup. Apparently the script has<br>
been around for eight years now.<br>
<br>
As the concrete issue reported in this issue seem to be the 'exit 2'<br>
part of the script, and you seem to know something about exit codes<br>
from ghdl, can you perhaps propose a better exit code to use in this<br>
wrapper script?<br>
<br>
-- <br>
Happy hacking<br>
Petter Reinholdtsen<br>
</blockquote></div>