Search Criteria
Package Details: evmone 0.15.0-1
Package Actions
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) |
Dependencies (6)
- gcc-libs (gcc-libs-gitAUR, gccrs-libs-gitAUR, gcc-libs-snapshotAUR)
- glibc (glibc-gitAUR, glibc-linux4AUR, glibc-eacAUR)
- benchmark (make)
- cli11 (make)
- cmake (cmake-gitAUR, cmake3AUR) (make)
- nlohmann-json (nlohmann-json-gitAUR) (make)
Required by (1)
- solidity (check)
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 insources
. 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
andintx
. These should really be separate packages. One forethash
even exists in AUR, but unfortunatelyethash-lib
is out of date whileethash-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 submittingintx
myself later and looking intoethash-lib
to see what's wrong with it.Building with tests enabled also turned out to be a bit problematic:
evmone-unittest
target fails to find theintx
andethash
headers when they're in a custom location, passed in viaCMAKE_PREFIX_PATH
(even thoughevmone
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.PKGBUILD
. I suspect this might be some yet unresolved incompatibility with CMake 4.makepkg --nocheck
and the extra dependencies need to sit inmakedepends
rather thancheckdepends
. 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
- Usecmake --build
instead of make for build - Run tests - license should beApache-2.0
for SPDX - depdends ongcc-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 urlMy 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.