vcpkg for macOs by daschuer · Pull Request #18 · mixxxdj/vcpkg

daschuer · 2021-06-30T12:23:29Z

This builds an environment for MacOS
Traget specific overlays have been moved to overlays/x64-osc and overlays/x64-win

The qt version of MacOs is 5.12.4, Windows is on 5.15.2

Be-ing · 2021-06-30T16:11:40Z

-        if(${VCPKG_OSX_DEPLOYMENT_TARGET} GREATER "10.14") # Max Version supported by QT
-            message(STATUS "Qt 5.12.4 only support OSX_DEPLOYMENT_TARGET up to 10.14")
-            set(VCPKG_OSX_DEPLOYMENT_TARGET "10.14")
+        if(${VCPKG_OSX_DEPLOYMENT_TARGET} GREATER "10.15") # Max Version supported by QT. This version is defined in mkspecs/common/macx.conf as QT_MAC_SDK_VERSION_MAX


Why is this change needed if we use 10.12 as the deployment target?

This is bugfix from upstream.

I'm unclear where it comes from. Is it backported from a later Qt version upstream?

Be-ing · 2021-06-30T18:14:01Z

Somehow uploading the logs of the Windows build broke:

No files were found with the provided path: C:\mixxx-vcpkg/buildtrees/**/*.log. No artifacts will be uploaded.

Be-ing · 2021-06-30T22:58:10Z

$ cmake -DCMAKE_TOOLCHAIN_FILE=buildenv/mixxx-deps-2.4-x64-osx-96ac0de/scripts/buildsystems/vcpkg.cmake -S . -B build
-- Setting CMAKE_BUILD_TYPE to 'Debug' as none was specified.
-- The C compiler identification is AppleClang 9.0.0.9000039
-- The CXX compiler identification is AppleClang 9.0.0.9000039
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - failed
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang - broken
CMake Error at buildenv/2.3-j00026-0b1209e3-osx10.12-x86_64-release/share/cmake-3.19/Modules/CMakeTestCCompiler.cmake:66 (message):
  The C compiler

    "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: /Users/bwilson/mixxx/build/CMakeFiles/CMakeTmp
    
    Run Build Command(s):/usr/bin/make cmTC_6907b/fast && make: error: unable to find utility "make", not a developer tool or in PATH
    
    

  

  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:61 (project)


-- Configuring incomplete, errors occurred!

daschuer · 2021-07-01T08:19:03Z

CMake Error at buildenv/2.3-j00026-0b1209e3-osx10.12-x86_64-release/share/cmake-3.19/Modules/CMakeTestCCompiler.cmake:66 (message):

why is this is still 2.3 ?

daschuer · 2021-07-01T08:47:53Z

Somehow uploading the logs of the Windows build broke

I guess there are non, because building is skipped due to caching.

Be-ing · 2021-07-01T11:05:20Z

why is this is still 2.3 ?

The vcpkg archive does not include cmake nor ccache, so I am still using those binaries from the old build environment.

Be-ing · 2021-07-01T11:09:19Z

Thank you for rebasing and cleaning up the commit messages. It looks like the new custom triplet is not working unfortunately.

Be-ing · 2021-07-01T22:26:18Z

There is no need to take care of these in this PR, but I would like to ship ccache and cmake with our macOS dependencies so macOS developers only need to download one archive besides the Mixxx source code. I do not know if upstream would accept packages for those because vcpkg is focused on libraries, but it is worth asking.

Be-ing · 2021-07-01T22:37:20Z

You could open an issue upstream to request this feature.

microsoft#18764

daschuer · 2021-07-01T23:14:03Z

Run Build Command(s):/usr/bin/make cmTC_6907b/fast && make: error: unable to find utility "make", not a developer tool or in PATH

Is make in your path?

daschuer · 2021-07-05T09:21:25Z

OK, It is building again. Merge?
This puts us in the situation that we can use the new environment in a PR and sort out remaining issues.

Be-ing · 2021-07-05T10:51:36Z

I would like to get this working locally or in a PR before merging. There may be changes needed in this branch to make it work still.

daschuer · 2021-07-05T11:49:59Z

Yes of cause there are probably remaining issues.
But without merging this current state no one else can help.

Wen we have the environment produced here on our download server, I can also continue to work on it fixing the mixxx repro or this one.

I think this was the way we have developed the Windows version as well.

Be-ing · 2021-07-05T11:51:32Z

If you make a branch on the mixxxdj/vcpkg repo, GitHub Actions will upload the build to downloads.mixxx.org which can be used for testing a PR in the mixxxdj/mixxx repo.

daschuer · 2021-07-05T12:06:27Z

Why do you think we need a branch? We have the same with less hassle when we just merge.

Be-ing · 2021-07-05T12:15:33Z

We can rebase a branch as needed until we merge it.

daschuer · 2021-07-05T12:30:00Z

Please explain the benefit?

Be-ing · 2021-07-05T12:37:57Z

a cleaner git history

There is no rush to merge until we know it works IMO. Do you have permission to push a new branch to this repo?

daschuer · 2021-07-05T12:58:47Z

I don't have interest to do more work for a clean history. This has gone already through a clean up which took me some
hours.

What is your current build output? Does installing make fix the issue?

daschuer · 2021-07-05T13:54:23Z

Using an relative path allows to use the original overlays/triplets folder.

Holzhaus · 2021-07-06T00:29:03Z

a cleaner git history

I think it's okay to merge as-is. This PR builds fine and there is no regression risk because we didn't use vcpkg for macOS until now. If further changes are necessary to make macOS build with vcpkg, the git history may as well reflect that.

daschuer · 2021-08-12T21:51:37Z

OK, I consider this as ready to merge now. It was tested together with Mixxx here:
https://github.com/daschuer/mixxx/runs/3315586893
I will issue a PR once this one is up at our download server.

Be-ing · 2021-08-12T21:53:47Z

Has it been tested by a macOS user?

Be-ing · 2021-08-13T03:41:58Z

My PR to upstream the fdk-aac fork without HE-AAC was merged. I will take care of removing it from our overlay after merging this.

Changing the default config in this overlay is required, because other required ports like harfbuz depend on the default configuration of this library

This allows using the port with imported targes form the mixxx module folder Fixes: microsoft#18442

…midi

Be-ing · 2021-08-14T13:05:12Z

Looks good to me as soon as we get confirmation from a macOS user that it is working.

daschuer · 2021-08-15T09:13:11Z

We have the confirmation that it works in terms of using the new libraries. I think we can merge and fix the found issues in the mixxx repro, linking to this new environment.
https://mixxx.zulipchat.com/#narrow/stream/267968-testing/topic/macOS.20build.20with.20vcpkg

Holzhaus · 2021-08-15T10:12:16Z

Alright, then I'll merge this now so that multiple people can contribute fixes if necessary instead of putting all the weight on @daschuer's shoulders. It won't make a difference for users/developers until we change the buildenv in the mixxx repo anyway.