Interesting. Even if I use the latest cmake from conda-forge I get the same
error though.
(temp) PS C:\temp\build> where.exe cmake
C:\Users\niran\miniconda3\envs\temp\Library\bin\cmake.exe
C:\Program Files\CMake\bin\cmake.exe
(temp) PS C:\temp\build> cmake --version
cmake version 3.24.1
CMake suit
The package you're using is from the `defaults` channels as opposed to
conda-forge in which the community doesn't control the recipe.
Only other thought is that if you're using a system `cmake` instead of a
conda supplied `cmake` then it won't properly search the conda prefix for
packages and will
This is what I got as the output.
(temp) PS C:\temp\build> cmake ..
-- Building for: Visual Studio 17 2022
-- Selecting Windows SDK version 10.0.19041.0 to target Windows 10.0.19043.
-- The CXX compiler identification is MSVC 19.31.31107.0
-- Detecting CXX compiler ABI info
-- Detecting CXX compil
All recent patches and updates have only been made to 8.0.1, but if you
share the package version you're using I was planning to poke around and
see if it turns out there's a broken package. That being said, I don't see
any changes in the commit history for the conda-forge package that should
have
Hi Keith,
Interestingly it was working with 8.0.1. So, I am guessing 8.0.0 Windows
artifacts have been overridden by the point release?
On Fri, Aug 19, 2022 at 12:00 PM Keith Kraus
wrote:
> Hey Niranda,
>
> Could you share exactly which 8.0.0 package you have installed? The output
> of `conda li
Hey Niranda,
Could you share exactly which 8.0.0 package you have installed? The output
of `conda list arrow-cpp` should show it.
On Thu, Aug 18, 2022 at 9:37 PM Niranda Perera
wrote:
> This issue is not there in v9.0.0 as well.
>
> On Thu, Aug 18, 2022 at 9:34 PM Niranda Perera
> wrote:
>
> >
This issue is not there in v9.0.0 as well.
On Thu, Aug 18, 2022 at 9:34 PM Niranda Perera
wrote:
> Hi all,
>
> I have Arrow v8.0.0 installed in my conda environment. Cmake (v3.24.0) is
> unable to find Arrow in Windows OS. I have no trouble running it in Linux
> though. We have been previously u
