search

fsprojects / FAKE

FAKE - F# Make
https://fake.build
Other
1.28k stars 582 forks source link

Replace Mono.Posix.NETStandard with Mono.Unix #2781

Open Numpsy opened 2 weeks ago

Numpsy commented 2 weeks ago

Description

A test followup to #2780, in the hope that replacing the old Mono.Posix.NetStandard with the newer Mono.Unix will work better on ARM macs and help get the CI builds working again. (I don't have an ARM mac to test with, so I'm guessing at some of this)

Numpsy commented 2 weeks ago

The way that the macOS tests timing out causes the Linux tests to abort is ever so slightly not helpful :-(

xperiandri commented 2 weeks ago

I have Mac M2. Do I just need to build and check if the build succeeds?

xperiandri commented 2 weeks ago

Why does it try to find something from net8.0 on CI?

xperiandri commented 2 weeks ago

Maybe we need this on CI? https://github.com/fsprojects/FSharp.Data.GraphQL/blob/4392616de6b3f427bf68d925b078e959658250ed/.github/workflows/publish_ci.yml#L32

Numpsy commented 2 weeks ago

I have Mac M2. Do I just need to build and check if the build succeeds?

Some of the integration tests seem to be getting an exception thrown from https://github.com/fsprojects/FAKE/blob/3f98e8d3ee4ae10aa127f2712222671f20f9367e/src/app/Fake.DotNet.Cli/DotNet.fs#L839 on the macOS runner. Maybe try calling that on an ARM mac and see if it works?

This change seems to avoid that error, though the CI run still fails.

Numpsy commented 2 weeks ago

I tried another build with a longer timeout at https://github.com/Numpsy/FAKE/actions/runs/9537030314 and the Windows run passed, but macOS and Linux both timed out running the integration tests, not sure why that is.

Why does it try to find something from net8.0 on CI?

Looks like some of the NuGet packages that it's installing have .NET 8 libs in them now and that causes warnings due to the old version of Paket in use, I don't know besides that.

xperiandri commented 2 weeks ago

I had the same until I applied my fix above

Numpsy commented 2 weeks ago

Hmm, looking at the CI logs for the mac build in more detail I see there's also this

DllNotFoundException: Unable to load shared library 'SQLite.Interop.dll' or one of its dependencies. In order to help diagnose loading problems, consider setting the DYLD_PRINT_LIBRARIES environment variable: dlopen(libSQLite.Interop.dll, 0x0001): tried: 'libSQLite.Interop.dll' (no such file), '/System/Volumes/Preboot/Cryptexes/OSlibSQLite.Interop.dll' (no such file), '/usr/lib/libSQLite.Interop.dll' (no such file, not in dyld cache), 'libSQLite.Interop.dll' (no such file), '/usr/local/lib/libSQLite.Interop.dll' (no such file), '/usr/lib/libSQLite.Interop.dll' (no such file, not in dyld cache)

from the issue #2007 - native libs work, so maybe that's another issue with a native lib on the ARM host?

xperiandri commented 2 weeks ago

I thought it runs on x64 on CI

Numpsy commented 2 weeks ago

I thought it runs on x64 on CI

The macOS-Latest runners are now using M1 CPUs - one of the effects of #2773 is to put in back to the older runners on Intel CPUs

Numpsy commented 2 weeks ago

Why does it try to find something from net8.0 on CI?

Actually, the integration tests at https://github.com/fsprojects/FAKE/blob/3f98e8d3ee4ae10aa127f2712222671f20f9367e/src/test/Fake.Core.IntegrationTests/Fake.DotNet.Cli.fs#L13 install the latest version of the .NET SDK, which is a moving target (there is a lot of stuff going on in here)

xperiandri commented 2 weeks ago

I expect that workaround that I mentioned has to work