GitLab

Downloading CUDA-11.1 from conda-forge takes a while

* Remove some obsolete conditions about CUDA-10.0 from `pkg_helpers.bash`.
* Use `USE_CUDA` instead of `FORCE_CUDA` in `pkg_helpers.bash`
* Do not define `NO_CUDA_PACKAGE` in build_wheel.sh and build_cuda.sh
* Add conda-forge for Win cuda-11.1 builds
* Pass USE_CUDA / TORCH_CUDA_ARCH_LIST to conda build
* Add selected CUDA to path
* Don't define USE_CUDA for ROCM

TODO: Fix Windows CUDA builds

Copy `cuda_install.bat` from
https://github.com/pytorch/vision/blob/3d9d264198e2167030dc04bf453aeca47daa37db/packaging/windows/internal/cuda_install.bat

Add `windows_intall_cuda` step and include it in `binary_windows_conda`
and `binary_windows_wheel` workflows

* Default to BUILD_SOX=1 in non-Windows systems

Since the adaptation of CMake and restricting to the static linking of libsox,
the build process has become much robust with libsox integration enabled.

This commit makes it default behavior to build libsox integration in non-Windows systems.
The build process still checks BUILD_SOX env var so, setting `BUILD_SOX=0` disables it.

* Pin MKL to 2021.2.0

Fixes https://github.com/pytorch/pytorch/issues/62424

* Apply the same  constraint for conda builds

Use less-than-equals constraint to avoid dependency conflicts for
python-3.6 environment

No longer needed for Python 3.9
Signed-off-by: Eli Uriegas <eliuriegas@fb.com>

There are some issues on CMake-based integration after 2021-06-19.

```
  Imported target "torch" includes non-existent path
    "/opt/conda/conda-bld/pytorch_1624259172741/work/torch/lib"
  in its INTERFACE_INCLUDE_DIRECTORIES.  Possible reasons include:
  * The path was deleted, renamed, or moved to another location.
  * An install or uninstall procedure did not complete successfully.
  * The installation package was faulty and references files it does not provide.
```

This is being worked on PR like https://github.com/pytorch/pytorch/pull/60403.
The nightly builds are still causing the error, so as a workaround, 
we pin the nightly build version for Linux/macOS unittest.
The issue still happens on Windows unittest and binary builds.

* add rocm binary

use the term cu_version

update pkg_helpers

add docker wheel option

update config yml

add force_cuda option

* update config.yml

* remove conda builds

* Add CUDA binary builds

* Add "cuda_version": "cpu" to doc build jobs

* Add required cu_versions to pkg_helpers

* Regenerate config.yml

All macOS CI jobs were failing at `brew`.
The issue was the macOS version `10.13`, which is no longer supported by `brew`.
The macOS version is indirectly controlled by `xcode` version as listed [here](https://circleci.com/docs/2.0/testing-ios/#supported-xcode-versions).

Updating the `xcode` to `"12.0"` as in PyTorch core bump macOS version to `10.15` and it resolves the issue.
`Python 3.9` is still failing but it's packaging issue on upstream, which needs to be resolved separately.

Should be moved back to stable once
https://github.com/pytorch/pytorch/issues/56654 is closed

This code was added as a part of investigation of inconsistent behavior
of file-like object support. Now the investigation is done and this code
does not provide much insight yet adding a bunch of lines to the log, so
this PR removes it.

Numpy is a dependency of pytorch so we should let it get resolved as it
install pytorch
Signed-off-by: Eli Uriegas <eliuriegas@fb.com>

Signed-off-by: Eli Uriegas <eliuriegas@fb.com>

* Switch to cmake for build
* Hide symbols

So that when a test fails in flaky manner, we can look into the difference.

* Do not install sox system-wide, so that it will never get mixed up with static one torchaudio builds
* Do not install cmake system-wide
* Move libsndfile installation to Docker image