Search Criteria
Package Details: bluespec-git r721.a6304315-1
Package Actions
Git Clone URL: | https://aur.archlinux.org/bluespec-git.git (read-only, click to copy) |
---|---|
Package Base: | bluespec-git |
Description: | Bluespec Compiler (BSC) |
Upstream URL: | https://github.com/B-Lang-org/bsc |
Licenses: | BSD |
Submitter: | Sequencer |
Maintainer: | Sequencer (thotypous) |
Last Packager: | thotypous |
Votes: | 7 |
Popularity: | 0.61 |
First Submitted: | 2020-02-05 02:51 (UTC) |
Last Updated: | 2024-06-01 15:58 (UTC) |
Dependencies (11)
- haskell-old-time
- haskell-regex-compat
- haskell-split
- haskell-syb
- ghc (ghc-cabal-artsAUR) (make)
- git (git-gitAUR, git-glAUR) (make)
- gperf (gperf-gitAUR) (make)
- tcl (tcl-fossilAUR, tcl84AUR) (make)
- texlive-fontsextra (texlive-installerAUR, texlive-fullAUR, texlive-dummyAUR) (make)
- texlive-latexextra (texlive-installerAUR, texlive-fullAUR, texlive-dummyAUR) (make)
- tcl (tcl-fossilAUR, tcl84AUR) (optional) – bluesim and bluetcl
Latest Comments
1 2 Next › Last »
xiota commented on 2024-09-05 19:40 (UTC)
Any reason not to drop the -M option? From Runtime system options, the default is unlimited.
Vekhir commented on 2024-09-05 13:17 (UTC)
@xiota Happens on my system too (for some time), though it's flaky; sometimes it builds and sometimes it doesn't. I worked around it by changing
-M5G
to-M8G
. Then it always works. Just tested again with-M5G
and it built once and failed once, with no apparent reason why.thotypous commented on 2024-09-05 11:10 (UTC)
@xiota compiler bug :S I encountered something like that back in 2020 and solved by finely adjusting $GHCJOBS and $GHCRTSFLAGS. However, it seems like it ended up building fine today 9:11 UTC at chaotic-aur.
xiota commented on 2024-09-05 08:48 (UTC)
Fails to build. bluespec-git.log
thotypous commented on 2024-06-01 16:18 (UTC)
@Vekhir Thanks a lot! That issue was in my TODO list, I was using Verilator simulations only until I had some time to look at it. You saved me a lot of time and now I can run Bluesim simulations again. Fix already applied to the PKGBUILD!
Vekhir commented on 2024-05-30 20:58 (UTC)
@thotypous Please add
CXXFLAGS+=" -ffat-lto-objects"
as suggested by [1] to solve the issue at [2].[1] https://gitlab.archlinux.org/pacman/pacman/-/issues/150#note_189104 [2] https://github.com/B-Lang-org/bsc/issues/704
thotypous commented on 2023-06-08 17:37 (UTC)
I ended up following @yan12125 advice and removing dynamic pkgrel.
Since a few months ago, we were already overriding it at chaotic-aur because it didn't work well (when some Haskell package's pkgver is incremented, pkgrel of that package is reset to 1, so the sum of pkgrels goes backwards), thus we devised another hack to bump pkgrel more properly at the builder.
Since the dynamic pkgrel is more of a hassle than useful for AUR helpers, and since it has no use anymore for the chaotic-aur builder, let's get rid of it.
yan12125 commented on 2023-06-06 14:26 (UTC)
Don't use dynamic pkgrel. It will not work as well-behaved AUR helpers rely on .SRCINFO to determine if a package is updated, and pkgrel in .SRCINFO is always static. Furthermore, it causes issues with namcap: https://gitlab.archlinux.org/pacman/namcap/-/issues/32. If users want to rebuild packages automatically, something like https://archlinux.org/packages/extra/any/rebuild-detector/ may be useful.
Vekhir commented on 2023-05-23 19:46 (UTC)
Hi, since the last commit, pkgrel is updated using pacman -Q, but that doesn't work when building from scratch in a clean chroot because the dependencies aren't yet installed (i.e. pacman -Q doesn't find the packages). The only similar option that
pacman -S
has is-l
to list all known packages with their versions, where we then have to manually grep our dependencies:eval pkgrel=$(pacman -Sl | grep -E $(echo "${depends[@]}" | sed -e 's: :|:g') | cut -d" " -f3 | cut -d"-" -f2 | awk '{sum+=$0}END{print sum}')
This works afaict and is probably the closest to the current version, whether it is faster than the previous one is unclear. It certainly doesn't depend on user settings, though the clean chroot deals with that already. What do you think?
thotypous commented on 2021-12-06 19:05 (UTC)
@Vekhir Since scripts should not rely on the structure of a particular language, we will instead add LC_ALL=C to force this particular command to produce English output. Please note, however, that it is preferable to always build packages in a clean chroot (and there would be no point in changing the locale of that chroot). You can find packages prebuilt by us on a clean chroot at https://pkgs.org/search/?q=bluespec or https://aur.chaotic.cx
1 2 Next › Last »