Fix openssl compile failure and download script on windows

[cz-kaga]

Usually, windows uses vcpkg to manage cmake packages. Now the build.rs file hardcoded ssl.lib and pkg-config command. Causing compile failure.

The fixes are AI generated, but I reviewd each line, I confirm there're no side effects about these fixes. The fix uses 5 stage to find openssl, including existing pkg-config way.

I run the tests on windows(x86_64)+msvc, result is: 161 passed, 1skipped.

My computer is: AMD Ryzen 3700X, 64GB RAM

[adsharma]

It's breaking Linux and likely Mac.

• download_lbug.sh (works on windows? you need bash installed, which is typical these days. Do we really need ps1?)
• other vcpkg stuff is ok, as long as it doesn't break other platforms and is minimal and self contained

Also vcpkg isn't the only way to get openssl3. It's possible to choco install.

[cz-kaga]

It's breaking Linux and likely Mac.

• download_lbug.sh (works on windows? you need bash installed, which is typical these days. Do we really need ps1?)
• other vcpkg stuff is ok, as long as it doesn't break other platforms and is minimal and self contained

Also vcpkg isn't the only way to get openssl3. It's possible to choco install.

It seems like there's no bash on Windows, if Windows users want to use bash, they have to install wsl(means using linux actually), or use git bash which may lack commands. So when I want to compile through msvc, the execution of sh script may be the problem. In Rust Project, there're three ways to solve the problem, the first is ps1 script, just like rustc, the second is build.rs embedded operation, the third is py script(maybe this is better, it is better and easier to convince windows developers configure python environment rather than bash, and python is embedded on Linux).

I'll check the availbility and test them on Linux and Mac, also I'll try to add choco support, thank you to point out.

[adsharma]

It's possible to use bash.exe on windows without WSL. Here's how the go workflow uses MSYS2.

https://github.com/LadybugDB/go-ladybug/blob/master/.github/workflows/go.yml#L57-L68

[cz-kaga]

Now I know the issue, MSYS2 using is the same to use gitbash, they are creating UNIX like shell, encouraging users to use gnu toolchain. So when someone depends on this crate and uses msvc toolchain(which is default on Windows), this crate will compile fail due to bash not found error, causing users' own project compile failure(that's what I encountered). This CI workflow runtime may use gnu toolchain. So the problem is not discovered, even though this is also the Windows environment.

Although it has the way to configure msys2+msvc environment, but it should first solve the conflict between msys2's link.exe and msvc's link.exe, yet maybe users just want to depend on it as the index backend(like me), configure msys2+msvc is too complicated compared to other crates on windows.

[cz-kaga]

I see workflow fails with

  thread 'main' (3786) panicked at build.rs:346:13:
  Failed to download ladybug source from https://github.com/LadybugDB/ladybug/archive/refs/heads/main.tar.gz
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Is it a network error? But previous log shows another problem of my fix. Not every unix systems' sh command support --version as an argument(such as dash). So in the nearest commits, build.rs will always try to run sh scripts first, only in sh trial failure and on windows platform should use ps1 script.

In additional, I found the path resolve problem when lbug-src download failed(only on windows branch), and the cmake dependency in Cargo.lock is too old to detect vs2026 msvc toolchain(I don't know why I could compile before, amazing). The newest commits fix them.

The test result still 161 passed, 1 skipped.

[adsharma]

Agreed on both points:

• We should make it easy for windows users to use this crate, without having to install lots of additional software. Although the direction MSFT is going (beyond WSL) is to install more UNIX utilities with Windows. But so far they're avoiding shipping bash.exe.

• The GH download issue is likely an infra issue. Did you see 503? That's an overload response.

[adsharma]

@cz-kaga can you send another PR to update the submodule pointer in the main repo?