alvis
/
fnm
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
136 Commits
1 Branch
66 Tags
4.3 MiB
Tree: 2799222b42
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '2799222b42'
${ noResults }
fnm/esy.lock/opam/cstruct-sexp.5.1.1/opam

40 lines
1.5 KiB
Raw Normal View History Unescape

Revert into using `ocaml-tls` instead of `ocaml-ssl` (#172) By statically linking `libgmp` on MacOS, we can avoid problems we have with OpenSSL, including dynamic linking (Fixes #110), and certificate issues (Fixes #170) Unfortunately, it makes fnm fail to build on Windows, which is not that of a big deal. I want to say thanks for @ulrikstrid for all the work he invested into making the build pass on Windows, but I think that implementing fnm on Windows will be better off as a separate program — maybe even in this very repo, while sharing the feature tests with the Unix implementation
5 years ago
opam-version: "2.0"
maintainer: "anil@recoil.org"
authors: ["Anil Madhavapeddy" "Richard Mortier" "Thomas Gazagnaire"
"Pierre Chambart" "David Kaloper" "Jeremy Yallop" "David Scott"
"Mindy Preston" "Thomas Leonard" "Anton Kochkov" "Etienne Millon" ]
homepage: "https://github.com/mirage/ocaml-cstruct"
license: "ISC"
dev-repo: "git+https://github.com/mirage/ocaml-cstruct.git"
bug-reports: "https://github.com/mirage/ocaml-cstruct/issues"
doc: "https://mirage.github.io/ocaml-cstruct/"
tags: [ "org:mirage" "org:ocamllabs" ]
build: [
["dune" "subst"] {pinned}
["dune" "build" "-p" name "-j" jobs]
["dune" "runtest" "-p" name "-j" jobs] {with-test}
]
depends: [
"ocaml" {>= "4.03.0"}
Fix "illegal instruction" errors on some CPUs (#177) This is done by pinning gmp to a fork of `esy-packages/esy-gmp` that uses the `--enable-fat` argument, suggested by @ulrikstrid. Here's the description of the open PR for `esy-packages/esy-gmp` https://github.com/esy-packages/esy-gmp/pull/3: > GMP uses [Intel ADX](https://en.wikipedia.org/wiki/Intel_ADX) to do math stuff when capable for performance reasons. The pick whether to use ADX or not is being chosen on compile time, unless you specify `--enable-fat` which creates a "fat" binary that decides on runtime whether to use these custom instructions: > > > Using --enable-fat selects a “fat binary” build on x86, where optimized low level subroutines are chosen at runtime according to the CPU detected. This means more code, but gives good performance on all x86 chips. (This option might become available for more architectures in the future.) > > Without this flag, users can get "illegal hardware instruction" errors when running their binaries on a machine without Intel ADX. > > So, in other words, this PR enables building gmp into a binary on CI which _has Intel ADX_, and then using it on a machine that does not have it (like AMD or older Intels) > > To me, it sounds like a sane default.
5 years ago
"dune"
"sexplib"
"cstruct" {=version}
Revert into using `ocaml-tls` instead of `ocaml-ssl` (#172) By statically linking `libgmp` on MacOS, we can avoid problems we have with OpenSSL, including dynamic linking (Fixes #110), and certificate issues (Fixes #170) Unfortunately, it makes fnm fail to build on Windows, which is not that of a big deal. I want to say thanks for @ulrikstrid for all the work he invested into making the build pass on Windows, but I think that implementing fnm on Windows will be better off as a separate program — maybe even in this very repo, while sharing the feature tests with the Unix implementation
5 years ago
"alcotest" {with-test}
]
synopsis: "S-expression serialisers for C-like structures"
description: """
Cstruct is a library and syntax extension to make it easier to access C-like
structures directly from OCaml. It supports both reading and writing to these
structures, and they are accessed via the `Bigarray` module.
This library provides Sexplib serialisers for the Cstruct.t values."""
url {
src:
Fix "illegal instruction" errors on some CPUs (#177) This is done by pinning gmp to a fork of `esy-packages/esy-gmp` that uses the `--enable-fat` argument, suggested by @ulrikstrid. Here's the description of the open PR for `esy-packages/esy-gmp` https://github.com/esy-packages/esy-gmp/pull/3: > GMP uses [Intel ADX](https://en.wikipedia.org/wiki/Intel_ADX) to do math stuff when capable for performance reasons. The pick whether to use ADX or not is being chosen on compile time, unless you specify `--enable-fat` which creates a "fat" binary that decides on runtime whether to use these custom instructions: > > > Using --enable-fat selects a “fat binary” build on x86, where optimized low level subroutines are chosen at runtime according to the CPU detected. This means more code, but gives good performance on all x86 chips. (This option might become available for more architectures in the future.) > > Without this flag, users can get "illegal hardware instruction" errors when running their binaries on a machine without Intel ADX. > > So, in other words, this PR enables building gmp into a binary on CI which _has Intel ADX_, and then using it on a machine that does not have it (like AMD or older Intels) > > To me, it sounds like a sane default.
5 years ago
"https://github.com/mirage/ocaml-cstruct/releases/download/v5.1.1/cstruct-v5.1.1.tbz"
Revert into using `ocaml-tls` instead of `ocaml-ssl` (#172) By statically linking `libgmp` on MacOS, we can avoid problems we have with OpenSSL, including dynamic linking (Fixes #110), and certificate issues (Fixes #170) Unfortunately, it makes fnm fail to build on Windows, which is not that of a big deal. I want to say thanks for @ulrikstrid for all the work he invested into making the build pass on Windows, but I think that implementing fnm on Windows will be better off as a separate program — maybe even in this very repo, while sharing the feature tests with the Unix implementation
5 years ago
checksum: [
Fix "illegal instruction" errors on some CPUs (#177) This is done by pinning gmp to a fork of `esy-packages/esy-gmp` that uses the `--enable-fat` argument, suggested by @ulrikstrid. Here's the description of the open PR for `esy-packages/esy-gmp` https://github.com/esy-packages/esy-gmp/pull/3: > GMP uses [Intel ADX](https://en.wikipedia.org/wiki/Intel_ADX) to do math stuff when capable for performance reasons. The pick whether to use ADX or not is being chosen on compile time, unless you specify `--enable-fat` which creates a "fat" binary that decides on runtime whether to use these custom instructions: > > > Using --enable-fat selects a “fat binary” build on x86, where optimized low level subroutines are chosen at runtime according to the CPU detected. This means more code, but gives good performance on all x86 chips. (This option might become available for more architectures in the future.) > > Without this flag, users can get "illegal hardware instruction" errors when running their binaries on a machine without Intel ADX. > > So, in other words, this PR enables building gmp into a binary on CI which _has Intel ADX_, and then using it on a machine that does not have it (like AMD or older Intels) > > To me, it sounds like a sane default.
5 years ago
"sha256=55d1f42cb85f7872fee499c5ed382aea17b06d55d1709e071d1ba85c7a09fef3"
"sha512=c3aa9a5a9125a1d022506a76fd7cdf32b21edcdc9df1202d8a9f382d02a28a33fea9a958f79e9302907ade1fce3f166b620c320aed6486e3efcc9a7464379cab"
Revert into using `ocaml-tls` instead of `ocaml-ssl` (#172) By statically linking `libgmp` on MacOS, we can avoid problems we have with OpenSSL, including dynamic linking (Fixes #110), and certificate issues (Fixes #170) Unfortunately, it makes fnm fail to build on Windows, which is not that of a big deal. I want to say thanks for @ulrikstrid for all the work he invested into making the build pass on Windows, but I think that implementing fnm on Windows will be better off as a separate program — maybe even in this very repo, while sharing the feature tests with the Unix implementation
5 years ago
]
}