The old `CC=.. CXX= .. meson ...` env var hack I removed in
3c00ca03a2 had a side effect of ensuring
that Meson always had access to a native C compiler, which unforunately
it expects in most cases. Thankfully, that will be fixed soon.
"Real" xcodebuild allows using `xcodebuild -version -sdk` without
an sdk version argument, which will dump sdk info for all the
installed sdks.
Bazel"s "xcode cc toolchain setup on mac" process uses this
to determine which SDK version is actually installed. This
change allows using a nix-supplied pinned compiler and build
system under bazel.
* treewide Drop unneeded go 1.12 overrides
* Fix packr to be go module compatible.
I updated to version 2.8.0 which is the latest on master.
Then due to the 2 different sets of go modules which are used, I split
the build into two different derivations, then merged them togethor
using symlinkJoin to have the same output structure as the existing derivation.
* Remove consul dependency on go1.12
I updated the consul version to 1.7.2 and flipped it to building using
modules.
* Remove go1.12 from perkeep.
Update the version to the latest unstable on master.
* Update scaleway-cli to not be pinned to go1.12
Switched the version to 1.20
* Update prometheus-varnish-exporter to not depend on go1.12
* Update lnd to build with go1.12
Updated the version
Forced only building subpackages with main to prevent panics over
multiple modules in one repo
* Remove go1.12 from openshift
Had to update the version to 4.1.0 and do a bit of munging to get this
to work
* Remove go1.12 completely.
These are no longer needed.
* Update bazel-watcher and make it build with go 1.14
The cross file is added in the `mkDerivation`. It isn't nice putting
build tool-specific stuff here, but our current architecture gives us
little alternative.
See comment in code and the PR it references,
https://github.com/mesonbuild/meson/pull/6827, for details.
We can remove entries from the cross file because they will be gotten
from env vars now.
Link the already-packaged typescript package so that ycmd will support
completions for javascript and typescript filetypes.
The structure of these installation directories is "documented" here:
<https://github.com/ycm-core/ycmd/blob/master/build.py>.
I don't completely understand why the language support is passed as
optional attrs Is it because folks want to build leaner packages and
pass null or because they want to target particular dependencies? At any
rate I followed the pattern.
This makes packages use lapack and blas, which can wrap different
BLAS/LAPACK implementations.
treewide: cleanup from blas/lapack changes
A few issues in the original treewide:
- can’t assume blas64 is a bool
- unused commented code
