* Update bazel-common to fix javadoc issues
Specifically, to fix the following error
```
ERROR: /home/aj/tweag.io/da/da-bazel-1.1/ledger-api/rs-grpc-bridge/BUILD.bazel:7:1: in javadoc_library rule //ledger-api/rs-grpc-bridge:rs-grpc-bridge_javadoc:
Traceback (most recent call last):
File "/home/aj/tweag.io/da/da-bazel-1.1/ledger-api/rs-grpc-bridge/BUILD.bazel", line 7
javadoc_library(name = 'rs-grpc-bridge_javadoc')
File "/home/aj/.cache/bazel/_bazel_aj/5f825ad28f8e070f999ba37395e46ee5/external/com_github_google_bazel_common/tools/javadoc/javadoc.bzl", line 27, in _javadoc_library
dep.java.transitive_deps
object of type 'JavaSkylarkApiProvider' has no field 'transitive_deps'
```
* Define Maven deps using rules_jvm_external
* Pin artifacts
* Remove bazel-deps generated targets
* Remove bazel-deps
* Switch to rules_jvm_external targets
* update bazel documentation
* pom_file: There are no more bazel-deps targets
* BAZEL-JVM.md `maven_install` typo
* Fix bazel query deps(//...)
* Add rules_haskell cc_wrapper
Updates to latest rules_haskell master and adds the cc_wrapper PR as a
patch, see https://github.com/tweag/rules_haskell/pull/1039.
* Shorten include dirs in cc-wrapper
When using `haskell_cabal_library` GHC constructs unnecessarily long
include directories which can quickly overflow the maximum command-line
length. This patch avoids the issue by normalizing include paths.
* glob --> breadth_first_walk
We currently use a custom cabal file for ghc-lib that has libffi in
the extra-libraries section so Hazel adds the headers. Forcing GHC to
use the bundled libffi should hopefully remove the need for this hack
which simplifies things.
* Delete obsolete proto3-suite patch
My patch has been upstreamed so no need to keep it around in our repo.
* Upgrade proto3-wire
* Adapt to changes in proto3-suite
This makes sure that C dependencies like gRPC or zlib get compiled
with optimizations. I patched rules_haskell to use -O instead of -O2
since the latter slows down compilation while not making things
faster (according to my measurements).
* Bump stackage
This PR switches us over to the latest Stackage LTS 0.14.1 (we were on
0.13.x before, so this includes major bumps) and gets rid of some
obsolete overwrites.
* Go back to building grpc-haskell-core using c2hs
This should hopefully avoid issues like the CSize vs CULong issue we
had a while back and might fix some of the issues we have been seeing
on CI.
I’m marking the Haskell ledger bindings as non-flaky for now so we can
see if the issues reappear.
* Fix path
* Fix c2hs runfiles
* s/basedir/dirname/
* Fix varname
* Remove fixme \o/
* Mark hs ledger bindings flaky again
For now, this only works on Linux (that’s a GHC limitation as far as I
know) and you have to enable it by setting the GHC_DWARF env var to a
non-empty string.
* Upgrade haskell-lsp and lsp-test
There have been some fixes upstream that should hopefully mean that we
no longer need to mark the lsp-tests as flaky on Windows. I am having
trouble reproducing the flakiness locally, so let’s see what happens
on CI.
* Also bump stack.yaml
* Upgrade ghc-lib
* Patch bazel_tools : hazel-include-paths patch, no-isystem patch.
* Provide "haskell_c2hs" for package name to cabal_haskell_package
* Package name haskell_c2hs => c2hs.
* Switch to less hacky patch for include dirs
* DA.Bazel.Runfiles based on bazel-runfiles
* locateRunfilesMb -> locateRunfiles
* .exe extension on Windows
* Add docstring to locateRunfiles
* bazel-runfiles: Normalize on Windows
* replace ApiValue ADT with aliases to daml-lf/transaction Value ADT
* porting rest of navigator to LF Value ADT
* porting more of navigator to LF Value ADT
* last error, not first
* rename ApiValueImplicits file
* special conversion features for ImmArray and FrontStack
- just .to[ImmArray] or .to[FrontStack] any random collection
* finish porting most of navigator main code
* use numeric indices for record field name fallback when pretty-printing
* tuples are not serializable
* use numeric indices for label fallback in JSON verbose encoding
* make traverseEitherStrictly more likely to preserve the seq's class
* to shortcut for ImmArraySeq .to[ImmArraySeq]
* compiling, passing navigator backend tests
* test traverseEitherStrictly more, er, strictly
* pass scalacopts through to scaladoc
* deal with unused warning
* remove unneeded function
* simpler error reporting, more private functions in ApiCodecCompressed
* move slowApply to FrontStack, test it so it actually works
* remove unneeded toStrings; better error from impossible ValueTuple case
* scalafmt FrontStackSpec
* support alternative, label-free record JSON encoding
* fuse some list operations
- suggested by @stefanobaghino-da; thanks
* blue error message
Python's `os.symlink` may fail on Windows if the user has insufficient
permissions to create symbolic links. This was not noticed on CI, since
builds there are executed with administrator privileges.
This changes `dev_env_package` to only outsource the listing of
directory contents to Python, but then fall back to Bazel's own
`repository_ctx.symlink` for the creation of symbolic links (or copies
if necessary).
* Bazel: 0.24.0 -> 0.27.0
* Update rules_haskell for Bazel 0.27 compatibility
* Update bazel-deps and bazel-watcher
* Windows escape JVM flags
* load commands at top of .bzl file
Bazel 0.27 no longer allows load commands that are not at the beginning
of the file.
* Update Bazel rules
* subpackage boundary
* native is not defined in BUILD files
* yarn: @bazel/hide-bazel-files
Seems to be required since latest rules_nodejs version. Otherwise, yarn
fails with errors about existing BUILD or BUILD.bazel files.
* grpc-java plugin visibility
* Update fat_cc_library
* Nix Python3 toolchain
* Iteration over depset
* dev_env_package: Create symlinks one level deeper
To prevent symlinking the BUILD file as well. The nested BUILD file
confuses Bazel as of 0.27 and rules_nodejs cannot find the node
executable anymore.
* Update rules_nodejs
* Add managed_directories for node_modules
* hie-bios: Extract bazel-genfiles from bazel info
Bazel 0.27 changed the genfiles location which breaks the hie-core test
on macOS.
* update cc_wrapper to Bazel 0.27
* bazel info -> bazel info bazel-genfiles
* Fix typo in BUILD
Co-Authored-By: Stefano Baghino <43749967+stefanobaghino-da@users.noreply.github.com>
* Fix running the IDE on damlc
There were two issues:
1. Missing include paths.
2. Files where the module name does not match the file name.
I’ve fixed both and added a test that we can load the damlc Main.hs.
* Update rules_haskell and static GHC
Remove patches that have been upstreamed or are no longer required.
Update still required patches to match the new rules_haskell version.
Previously we patched rules_haskell to coerce GHC into using static
Haskell libraries in most places. In particular we moved hs-libraries
entries into extra-libraries entries in the package configuration files.
A much cleaner approach is to compile GHC with a static RTS, then GHC
will by itself choose to load static Haskell libraries.
* Remove haskell_cc_import
* da-hs-daml-cli -> daml-cli
* da-hs-damlc-app -> damlc-app
* windows: root build
* windows: fixed haskell bindings tests
* windows: disable client_server_test test
* windows: marking daml_test flaky due to #1907
* windows: removing da-hs-damlc-app run from build.ps1
* windows: disable hie-core alias of currently disabled target
* Fix CPP issue with default da-ghci
The default REPL target did not exclude the //nix targets that set the
CPP language extensions.
* da-ghci -e () requires explicit target
Running the tests via the ledger-api-test-tool results in a nasty
runtime exception. This check only fixes paths if it detects a bazel
environment.
Fixes#1841
* Update the hie-bios commit SHA
* Also update the SHA in our bazel WORKSPACE
* Update the hash too
* Tutorial for Emacs integration
* Update hie-bios patch
* Fixes#1204: Release bindings and codegens to Maven Central.
Upload the Java and Scala Bindings with the respective code
generator binaries to Sonatype Open Source Repository
Host for synchronization with Maven Central.
