Package Details: evmone 0.15.0-1

Git Clone URL: https://aur.archlinux.org/evmone.git (read-only, click to copy)
Package Base: evmone
Description: Fast Ethereum Virtual Machine implementation
Upstream URL: https://github.com/ethereum/evmone
Keywords: eth ethereum evmone
Licenses: Apache-2.0
Submitter: marenz
Maintainer: marenz (cameel)
Last Packager: cameel
Votes: 3
Popularity: 0.000000
First Submitted: 2019-08-12 17:50 (UTC)
Last Updated: 2025-04-13 19:47 (UTC)

Latest Comments

cameel commented on 2025-04-13 19:55 (UTC) (edited on 2025-04-13 19:59 (UTC) by cameel)

@Xeonacid Thanks, I applied your suggestions and also generally refactored the package. It always bothered me that it was just cloning the repo as if it were a -git package rather than building from source. Now the package is built completely from the source tarballs declared in sources. And not just the submodules but also the dependencies that used to be fetched with Hunter at build time. Once you have the sources, the build is not completely off-line.

There are still some rough edges though.

The package now builds ethash and intx. These should really be separate packages. One for ethash even exists in AUR, but unfortunately ethash-lib is out of date while ethash-lib-git results in missing symbols during linking. If anyone wants to maintain these, I'd switch the package to use them. Otherwise, I'll consider submitting intx myself later and looking into ethash-lib to see what's wrong with it.

Building with tests enabled also turned out to be a bit problematic:

  • When building from tarballs, the evmone-unittest target fails to find the intx and ethash headers when they're in a custom location, passed in via CMAKE_PREFIX_PATH (even though evmone target in the same build finds them just fine). I think this may be some minor issue in project's CMake. It does not happen when building with Hunter or when the dependencies are installed globally so it may have never been noticed before.
  • When building with Hunter, the target fails too, just in a different way. It can't build the CLI11 library. I'm getting that when using your PKGBUILD. I suspect this might be some yet unresolved incompatibility with CMake 4.
  • Finally, it's not possible to reconfigure the build to enable/disable testing by rerunning CMake (I'm getting errors trying that). This means that I always have to build with testing enabled and this comes with some downsides. First, the build is quite a bit heavier and longer, even if you run makepkg --nocheck and the extra dependencies need to sit in makedepends rather than checkdepends. Second, this enables some extra test-only artifacts for benchmarking that I have to remove manually afterwards.

I'm going to report these test issues upstream, but for now I just had to add some hacks to work around them.

Xeonacid commented on 2025-01-21 13:49 (UTC)

Some improvements to follow package guidelines: - arch should be x86_64 - Use cmake --build instead of make for build - Run tests - license should be Apache-2.0 for SPDX - depdends on gcc-libs glibc - gcc don't need to be in makedepends as it's in base-devel - Checksum should not be skipped - Add submodules to source array and change submodule url

My adjusted PKGBUILD can be used as a reference.

I'd like to co-maintain the package if applicable.

marenz commented on 2019-12-02 16:57 (UTC)

I was wondering why this site still showed the old version

ekpyron commented on 2019-11-29 15:56 (UTC)

https://wiki.archlinux.org/index.php/.SRCINFO

ekpyron commented on 2019-11-29 15:56 (UTC)

You did update the PKGBUILD, but you didn't update .SRCINFO, so the displayed version is incorrect and AUR package managers won't detect the update.