brotli.1.2.0 - via opam-publish

[fxfactorial]

Bindings to Google's Brotli compresion algorithm

OCaml Bindings to brotli, Google's compression algorithm for the web
Source: https://github.com/google/brotli/ RFC:
http://www.ietf.org/id/draft-alakuijala-brotli

---

• Homepage: http://hyegar.com
• Source repo: https://github.com/fxfactorial/ocaml-brotli.git
• Bug tracker: https://github.com/fxfactorial/ocaml-brotli/issues

---

Pull-request generated by opam-publish v0.3.2

[fxfactorial]

1. Okay, this one isn't my fault, I put -cc clang++ in my build and I specifically ask for clang in my depexts.
2. The OS X build should work but I guess the travis machine doesn't respect opam depext?

[dsheets]

On OS X:

# src/brotli_stubs.c:10:10: fatal error: 'brotli/decode.h' file not found
# #include <brotli/decode.h>
#          ^
# 1 error generated.
# Command exited with code 2.

On Linux with OCaml 4.03:

# gcc: error: unrecognized command line option ‘-fsanitize=undefined-trap’
# gcc: error: unrecognized command line option ‘-fsanitize-undefined-trap-on-error’
# gcc: error: unrecognized command line option ‘-std=c++14’

Are you setting -cc to clang? Do you need to modify the include path on OS X?

[fxfactorial]

@dsheets On OS X it should be fine out the box, in theory, because I have an install script under depexts:

[["source" "osx" "linux"]
   ["https://raw.githubusercontent.com/fxfactorial/ocaml-brotli/master/prepare.sh"]]

(The install script is needed because libbrotli isn't done by google itself but its a third party lib and none of the package managers have it yet.

For Linux, I'm using this in my _oasis file:

NativeOpt:
    -cc clang++ -g -w +a-4-40..42-44-45-48 -O2
    -cclib -fsanitize=address -ccopt -fsanitize=address
  ByteOpt:
    -cc clang++ -g -w +a-4-40..42-44-45-48
    -cclib -fsanitize=address -ccopt -fsanitize=address

[dsheets]

This set of tags is a conjunction and so will never pass (there is no environment that is both osx and linux).

[fxfactorial]

Oh my mistake, I will fix it now and then force push.

[fxfactorial]

More pain is that depext doesn't let you test locally, you have to have it published as a package; also tried locally pinning the package.

[dsheets]

This URL is not versioned and we would really not like to use source installation of depexts as they can have nasty side effects (global system changes, network retrievals, etc). Homebrew ships a library called brotli of version 0.5.2. Is that one not sufficient?

[fxfactorial]

That's not a library, its an executable

[dsheets]

That's sad. I really encourage you to take a look at google/brotli#326 and related PRs/features and perhaps submit a PR to homebrew to update the brotli package to also install headers and shared libraries. Another option is to bundle the brotli source code with your package and build and link with it which would work on OS X or Linux. Either of these options is much more preferable to having source depexts which are generally regarded as dangerous and unfriendly to users. Finally, simply ignoring the depexts system and including a build failure message telling users they need to install brotli libraries (and where to get them) would also be fine.

[fxfactorial]

@dsheets yea, I know about libbrotli, I have commits on it as well. Google doesn't seem to be moving on this for quite some time.

Okay, then I'll just do a build failure message and remove the depext. I don't understand why offer a feature and then tell people not to use it...then remove it?

[dbuenzli]

I don't understand why offer a feature and then tell people not to use it...then remove it?

Other (e.g. private) OPAM repositories may have different policies.

[dbuenzli]

Is this message needed ? I think depexts are automatically advertised and suggested to be run in case of build failure.

[fxfactorial]

Apparently it doesn't matter in this case anyway, so I'll lessen it

[dbuenzli]

I'm not sure that post-messages is a suitable place for sample code. Sample code should go in the doc: directory of the package.

[fxfactorial]

I respectfully disagree, its nice to have some quick high level idea of how to use a library, I think I've seen some npm packages do this as well (Merlin provides a similiar thing in its post-message install)

[dbuenzli]

its nice to have some quick high level idea of how to use a library

I'm not saying you should not provide sample code. I'm saying that this is not the place to provide it. Here are a few reasons:

1. What do I do if want to go back to that sample code later, reinstall the package ?
2. This gets output on each install of the package, the user may not care about this because e.g. it is pulled through a dependency or because he already knows how to use the package. In this case this is only polluting OPAM's output with irrelevant noise.
3. The best of way of providing this to the end-user in the library's API documentation, that's the natural place a programmer will look for it.

[fxfactorial]

Okay you're right, I concede.

[fxfactorial]

@dsheets @dbuenzli okay, removed the depext and lowered the messages but still not sure how to make sure that clang++ is the one used on Linux which I have a suspicion that there isn't one...since _oasis will use what ocamlc -config gives....

[dsheets]

Thanks!