Repository: pytorch
Issue: Generic BLAS provider incorrectly considered "found"
Labels: module: build,triaged

### 🐛 Describe the bug

When the BLAS provider is configured to be `"Generic"` Torch's `Dependencies.cmake` executes [the following logic](https://github.com/pytorch/pytorch/blob/main/cmake/Dependencies.cmake#L236-L241):

```
  find_library(BLAS_LIBRARIES NAMES ${GENERIC_BLAS})
  message("-- Using BLAS: ${BLAS_LIBRARIES}")
  list(APPEND Caffe2_DEPENDENCY_LIBS ${BLAS_LIBRARIES})
  set(GENERIC_BLAS_FOUND TRUE)
  set(BLAS_INFO "generic")
  set(BLAS_FOUND 1)
```
However, this does not take into consideration the case in which `find_library` does not actually find the BLAS library. In such as case the variable `BLAS_LIBRARIES` is set to `BLAS_LIBRARIES-NOTFOUND`. However, the above logic _always_ sets the status of BLAS detection to a positive result, meaning in this case we have a false positive.

```
list(APPEND Caffe2_DEPENDENCY_LIBS ${BLAS_LIBRARIES})
```

Then incorporates the variable into the link interface.

We can oberved output like

```
  -- Using BLAS: BLAS_LIBRARIES-NOTFOUND
```

from the build and finally a generate time error like:

```
  CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
  Please set them or make sure they are set and tested correctly in the CMake files:
  BLAS_LIBRARIES
      linked by target "torch_cpu" in directory C:/spack/py-torch-2.4.1-xselqwv/spack-src/caffe2
      linked by target "torch_cpu" in directory C:/spack/py-torch-2.4.1-xselqwv/spack-src/caffe2
```
From [these lines (included inline below)](https://github.com/pytorch/pytorch/blob/main/cmake/Dependencies.cmake#L249-L251)

```
 if(NOT (ATLAS_FOUND OR BLIS_FOUND OR GENERIC_BLAS_FOUND OR MKL_FOUND OR OpenBLAS_FOUND OR VECLIB_FOUND OR FlexiBLAS_FOUND OR NVPL_BLAS_FOUND))
    message(WARNING "Preferred BLAS (" ${BLAS} ") cannot be found, now searching for a general BLAS library")
    find_package(BLAS)
```

It's clear that failing to find the generic provider should result in this fallback strategy being implemented. Instead, regardless of whether BLAS is found or not, we skip this logic, and wind up with an incomplete CMake run.


### Versions

```
PyTorch version: N/A
Is debug build: N/A
CUDA used to build PyTorch: N/A
ROCM used to build PyTorch: N/A

OS: Microsoft Windows 11 Pro
GCC version: Could not collect
Clang version: Could not collect
CMake version: version 3.29.3
Libc version: N/A

Python version: 3.11.3 (tags/v3.11.3:f3909b8, Apr  4 2023, 23:49:59) [MSC v.1934 64 bit (AMD64)] (64-bit runtime)
Python platform: Windows-10-10.0.22631-SP0
Is CUDA available: N/A
CUDA runtime version: 11.3.58
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: GPU 0: Quadro T2000
Nvidia driver version: 555.99
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: N/A

CPU:
Architecture=9
CurrentClockSpeed=2304
DeviceID=CPU0
Family=207
L2CacheSize=2048
L2CacheSpeed=
Manufacturer=GenuineIntel
MaxClockSpeed=2304
Name=Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
ProcessorType=3
Revision=

Versions of relevant libraries:
[pip3] flake8==6.1.0
[pip3] mypy==1.10.0
[pip3] mypy-extensions==1.0.0
[pip3] numpy==1.26.0
[conda] Could not collect
```

As this was a CMake failure, there's no built pytorch, and the MSVC version was irrelevant.
FWIW this error was observed by the Spack project.

cc @malfet @seemethere