I'd like to ask that ghdl be brought back (or at least get the discussion going). ghdl can be built with gnat-gpl and the modern versions of ghdl don't seem to require any out of date packages (I'm building on stock gentoo). Also, the llvm version provides very nice speed without all the complexity of the gcc build process. Long story short, what would it take to bring ghdl back? To be clear I'm suggesting that I provide a stand alone ebuild that works without requiring any other packages and providing the upkeep.
https://github.com/ghdl/ghdl
Here's my first run at an ebuild. Basically it (kludge) fixes the cooky configuration system that ghdl uses to handle things like lib dirs and the like. This is the llvm configuration. I'll probably add the other two in the future. I could use some help testing the dependencies. Is there an automated system for this?
Created attachment 567692 [details] ghdl-0.36.ebuild
Created attachment 567694 [details, diff] ghdl_configuration.patch
Created attachment 567696 [details] Test case Test by: $ ghdl -a test2.vhdl $ ghdl -e hello_world $ ghdl -r hello_world Hello world!
Created attachment 568586 [details] New version of ghdl-0.36 ebuild Fixed ebuild for those who haven't misconfigured their gcc version to be the gnat-gpl version (oops). Now with USE flags for gnat version, used gprbuild-2017-r1.ebuild as a template.
Poke. Is there anything I can do to further push this along? This is a very useful tool that I think a lot of people use. It's been updated to make the build process be much more friendly. It still needs some modification as indicated in the patch I attached, but it's not at all as involved as it used to be. Can we get this back in portage please?
hi Alex Orange, thank you for your effort! I massively use ghdl for my HDL designs and I do appreciate your attempt to resurrect the ebuild. I am currently using ghdl-v0.29 on an old stage4-i686-2014. Yesterday I downloaded a fresh new Gentoo-stage3 and start emerging things. I have just tried your ebuild, I got this error. >>> Emerging (1 of 1) sci-electronics/ghdl-0.36::gentoo * ghdl-0.36.tar.gz BLAKE2B SHA512 size ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking ghdl-0.36.tar.gz to /var/tmp/portage/sci-electronics/ghdl-0.36/work >>> Source unpacked in /var/tmp/portage/sci-electronics/ghdl-0.36/work >>> Preparing source in /var/tmp/portage/sci-electronics/ghdl-0.36/work/ghdl-0.36 ... * Applying ghdl_configuration.patch ... [ ok ] >>> Source prepared. >>> Configuring source in /var/tmp/portage/sci-electronics/ghdl-0.36/work/ghdl-0.36 ... ./configure --prefix=/usr --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib --with-llvm-config Use full IEEE library Build machine is: i686-pc-linux-gnu Unhandled version llvm 10.0.0
solved it in a different way I forced an old gcc v4.9.4 as CC. It got installed in /opt/gccada-4.9.4 and redirected as "main compiler". This compiler is an "ada bootstrapper" and it's compiled with enable-languages="c,c++,ada", thus is able to compile ada stuff. So I then simplified the ghdl-0.3*.ebuild and used gccada-4.9.4 to compile ghdl. It worked for ghdl-0.35, 0.36 and 0.37 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - sci-electronics/ghdl v0.35 succesfully compiled with gccada-4.9.4 sci-electronics/ghdl v0.36 succesfully compiled with gccada-4.9.4 sci-electronics/ghdl v0.37 succesfully compiled with gccada-4.9.4 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - EAPI=6 DESCRIPTION="VHDL 2008/93/87 simulator" HOMEPAGE="http://ghdl.free.fr/" SRC_URI="https://github.com/ghdl/ghdl/archive/v${PV}.tar.gz" LICENSE="GPL-2" SLOT="0" KEYWORDS="x86" IUSE="" GCC_PV=4.9.4 DEPEND="dev-lang/gnat-gpl:${GCC_PV}" RDEPEND="${DEPEND}" src_configure() { ./configure --prefix=/usr } src_compile() { emake }
Sorry, did *not* mean to abandon this. I've added a few more packages that I think are setup a bit more how they should be (at least somewhat parameterized for different ADA and LLVM packages). Again, if someone who understands ebuild packaging could give some pointers I'd be happy to improve these, definitely still want these packages added though!
Created attachment 669935 [details] Updated ebuild for 0.37.0 Updated ebuild for v0.37.0 and (I believe) improved it significantly irrespective of ghdl version (have yet to backport improvements to 0.36).
Created attachment 669938 [details, diff] Patch needed for the 0.37.0 ebuild (in files dir)
Created attachment 669947 [details, diff] Oops, didn't test the install phase. This one tested, and ghdl itself tested after.
I just want to throw in that I also made an ebuild for ghdl-0.37 in the past, as I needed it... https://github.com/zseri/portage-zscheile/blob/437fc82976f904de2577c3ddb9052271ccf7949c/sci-electronics/ghdl/ghdl-0.37.ebuild
Just a note, the tarball gets saved without the package name: ... 2021-03-26 21:35:01 (4.66 MB/s) - '/usr/portage/distfiles/v0.37.0.tar.gz.__download__' saved [4775092] Grepping for SRC_URI.*github in /usr/portage, it appears the solution is to change the line like so: -SRC_URI="https://github.com/ghdl/ghdl/archive/v${PV}.tar.gz" +SRC_URI="https://github.com/ghdl/ghdl/archive/v${PV}.tar.gz -> ${P}.tar.gz" I added a hunk to the patch, modifying configure to accept LLVM 11.1 (the version I have). Essentially @@ -279,6 +307,7 @@ ... + check_version 11.1 $llvm_version || ... Back in the ebuild, I got rid of the llvm version restrictions and enabled synthesis, though not in a kosher manner. With these modifications it builds. In addition, I grabbed a few test files from the ghdl source and it seems to function correctly.
Mark, thanks for pointing that out. I've added that and bumped this to the next version (with some patch tweaking). To whomever is in the sci-electronics list: 1. Is there anything against putting this back in? 2. I would be happy to be the maintainer for this. 3. Assuming 1&2 are good, what would be the process of doing this? The version I have for 1.0.0 also requires two other dev-python ebuilds for features related to testing.
Created attachment 736729 [details] ghdl v1.0.0 ebuild
Created attachment 736732 [details, diff] Configuration patch for ghdl v1.0.0
I seem to have a recurring "need" for fpga/verification tools, so I've added a modified version of this to the new/clean-ish embedded-overlay for now. I think we probably *do* want this in the tree, so "we" might as well get it cleaned up a little more first (and by "we" I mean mostly Alex Orange ;) https://github.com/VCTLabs/embedded-overlay Please fork and test out the tools, make a PR, dance a jig, and let me know what you think.
GHDL 1.0.0 (plus the deps in the overlay) can run all the tests now, but the newer stuff throws in even more python deps (and thus needs more work). I'll take a look at splitting out the pyGHDL package for now.
(In reply to Steve Arnold from comment #20) > GHDL 1.0.0 (plus the deps in the overlay) can run all the tests now, but the > newer stuff throws in even more python deps (and thus needs more work). I'll > take a look at splitting out the pyGHDL package for now. Regarding the tests, upstream didn't intend to be run when the package is not installed yet so this leads to a failure during first installation, see also: https://github.com/ghdl/ghdl/issues/1255 https://github.com/ghdl/ghdl/issues/1399 I managed to implement a workaround of the issue with the following src_test() for version 1.0.0, now we can run successfully all of tests: src_test() { # testsuite assumes an already installed instance, not from build dir mkdir "${S}"/{include,lib} ln -s "${S}"/src/grt/vpi_user.h include/ ln -s "${S}"/libghdlvpi.so lib/ GHDL_PREFIX="${S}/ghdl" default } I agree that they take a lot of time but tests are not executed by default on Gentoo so I'd prefer to avoid running only a subset as proposed in the embedded-overlay
Can I ask what the current state of ghdl is? I adapted a version from the https://github.com/VCTLabs/embedded-overlay (without the tests) for my own overlay with LLVM 14+15 and gcc12 patches for ghdl-2.0.0, also added a 9999-git version due to the much better support of VHDL-2008 features. I have not much experience in writing "clean" ebuilds (apart from making it work for myself) but am more than happy to help (and learn). Gtkwave is already in the tree maintained by the Electronics Project, only thing left is the/an actual simulator :)
I don't know what the current state is. I very much need it for my day to day work and will probably try to make an overlay for it. It is very sad that this bitrotted its way out of portage.
P.S. If any of the devs want to set a list of requirements to reintegrate some ebuilds back into portage I'd be happy to put some work into making that happen.
I understand the frustration, I kind of need it, too (not very regularly though). My current ebuild is (if you want to get a start without re-doing some work): https://gitlab.com/f14h/f14h_overlay/-/blob/master/sci-electronics/ghdl/ghdl-9999.ebuild The patches don't apply cleanly anymore, the master branch is very fast moving and has much better vhdl-2008 support than 2.0.0. It was working "Wed Dec 28 16:47:19 2022" according to genlop. Until version 3.0.0 (or something) comes out, maybe the ebuild should use a certain commit? If you would like some help, I'm happy to try (as I said though, not much experience yet).
Alex, Frederik, I added ghdl, version 3.0.0 to the min ::gentoo tree.