New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

add custom macOS triplet for Qt6 #26

Merged

Be-ing merged 2 commits into mixxxdj:2.4 from Be-ing:osx_triplets

Oct 18, 2021

Be-ing commented Oct 16, 2021

No description provided.

Be-ing added 2 commits

October 16, 2021 11:54


          add custom x64-osx-min10.14 triplet for Qt6

5922fe9


          rename confusing x64-osx overlay triplet to x64-osx-min10.12

1d83f75

daschuer requested changes

View reviewed changes

Member

daschuer left a comment

I am afraid your renaming is not working.
I suggest to introduce another sub folder and stick with x64-osx.triplet for both.
I think exist an implicit naming convention a triplet of:
ARCHITECTURE-OS-PLATFORM.triplet

The green checkmark here is not significant, because it now falls Fack to the default x64-osx triplet

Author

Be-ing commented Oct 17, 2021 •

edited

Loading

It is working fine here: mixxxdj/mixxx#4432

There is no need to reuse the x64-osx name. That would be confusing for no particular reason.

Be-ing mentioned this pull request

vcpkg manifest mode mixxxdj/mixxx#4432

Closed

Member

daschuer commented Oct 17, 2021

The triplet name x64-osx-mixxx was not working reliable after following your suggestion here:
#18 (review)

Unfortunately I cannot find the failure log anymore. I only know that the error was hard to discover and took me many ours because the error message was not mentioning the triplet file, and the error did not apperars instantly after renaming the triplet file because of caching.

Let's not repeat this.

Author

Be-ing commented Oct 17, 2021

The use of x64-osx for the custom triplet caused me some confusion working on mixxxdj/mixxx#4432. Before I set the host triplet, the Qt6 build failed because it fell back to using x64-osx which was set to a minimum target macOS 10.12 which is lower than what Qt6 supports.

Whatever trouble you ran into before is not happening in manifest mode with mixxxdj/mixxx#4432 so I don't think we need to worry about it.

Author

Be-ing commented Oct 17, 2021

the error did not apperars instantly after renaming the triplet file because of caching

This will not be an issue with manifest mode.

Member

daschuer commented Oct 17, 2021

If you are sure it is working, fine. But be warned.

Member

daschuer commented Oct 17, 2021

Please Update the GitHub workflow to use the new triplet name.

Author

Be-ing commented Oct 17, 2021

I have removed the GitHub Actions workflow from this repo in #29.

Member

daschuer commented Oct 17, 2021

That's not yet merged. We have currently no CI for the new triplets. So please adhust the names her to have a significant test.

Author

Be-ing commented Oct 17, 2021

That is circular reasoning. We cannot merge mixxxdj/mixxx#4432 without this and you are saying to not merge this.

Author

Be-ing commented Oct 17, 2021

Please stop putting unnecessary obstacles in the way of progress.

Author

Be-ing commented Oct 17, 2021

mixxxdj/mixxx#4432 is the CI for this.

Member

daschuer commented Oct 17, 2021

But it is failing.

Author

Be-ing commented Oct 17, 2021

only because Mixxx does not build with Qt6 yet

Author

Be-ing commented Oct 18, 2021

Let's merge this then I can switch the submodule in mixxxdj/mixxx#4432 from my branch to this repo.

Member

daschuer commented Oct 18, 2021

You should really enable the Ci with the new triplet. It is just a one line change and 4 h waiting.
microsoft#4432 has no significant log output and no build artifacts. I think it will take a bit until it is mature.
Once the CI is done this can be merged and we can update the mixxx main with the new hash.
Lets go in small steps.

Be-ing merged commit 1b70fe2 into mixxxdj:2.4

Author

Be-ing commented Oct 18, 2021

This bikeshedding helps nobody.

Be-ing deleted the osx_triplets branch

October 18, 2021 01:51

Author

Be-ing commented Oct 18, 2021

Running CI on this repo is utterly pointless and a waste of time and electricity.

no significant log output and no build artifacts

This is not true. Just because you were not looking at them does not mean they do not exist. I have been spending days looking at the log outputs.

Author

Be-ing commented Oct 18, 2021 •

edited

Loading

I think it will take a bit until it is mature.

This was incredibly infuriating to read. I have already taken enough insults about the quality of my work (that other people aren't doing). I have spent days toiling over GitHub Actions logs, sometimes waiting over 4 hours to find out the effects of my changes. It works. I know it works. Just because you weren't paying attention doesn't mean I wasn't.

Member

Holzhaus commented Oct 18, 2021

@Be-ing I think we have a concensus that it's not okay to merge your own PR. Especially when there is no approval and a reviewer explicitly requested changes.

If you think that the discussion goes in circles and is not productive anymore, you may call for a vote and we can decide as a team how to continue. If you consider this approach insufficient, we can also check if we can find a better governance model by discussing it on Zulip. But ignoring the opinion of other devs without a majority decision is not okay.

Author

Be-ing commented Oct 18, 2021

you may call for a vote and we can decide as a team how to continue

This requires other people to pay attention and speak up, not let one person get their way just by being willing to repeat themselves more than anyone cares to argue with.

Member

Holzhaus commented Oct 18, 2021 •

edited

Loading

This requires other people to pay attention and speak up, not let one person get their way just by being willing to repeat themselves more than anyone cares to argue with.

You did not even try to get a majority decision. By the time you merged it, the PR was less than 1 1/2 days old. That is not much time for a volunteer project.

Letting one person get their way by being willing to ignore our decision making process and abuse commit privileges isn't any better. Please don't do this.

Author

Be-ing commented Oct 18, 2021

Sorry. I got extremely frustrated by @daschuer insulting my work. I did nothing but work on this for several days straight, and now I get insulted for it?!??

Holzhaus mentioned this pull request

Reintroduce the Quick effect selectors in the EQ preferences mixxxdj/mixxx#4486

Merged

daschuer mentioned this pull request

Merged

This was referenced Dec 17, 2021

Update to latest vcpkg commit mixxxdj/mixxx#4570

Closed

Set VCPKG_DEFAULT_HOST_TRIPLET #38

Merged

daschuer pushed a commit to daschuer/vcpkg that referenced this pull request


          [cairomm] update to 1.16.1 (microsoft#23904)

3f7655c

* [cairomm] update to 1.16.1 (microsoft#23903)

Cairo:
* Surface::Type: Deprecate WIN32, add WIN32_SURFACE
  (Kjell Ahlstedt) Issue mixxxdj#26, merge request !14

Build:
* cairommconfig.h.*: Don't dllimport on MinGW
  (Chun-wei Fan) Merge reqest !16
  (Chun-wei Fan) Issue gtkmm#90 (Lukas K.)
* Meson build: Make it possible to use cairomm as a subproject
  (Kjell Ahlstedt)
* Meson build: No implicit_include_directories
  (Kjell Ahlstedt)
* MSVC build: exception.h: Export Cairo::logic_error selectively
  (Chun-wei Fan) Merge request !17

* [cairomm] remove patch (microsoft#23903)

The WIN32 constant has been renamed to WIN32_SURFACE , and the
WIN32 -> WIN32_SURFACE alias is only provided for non-win32
sytems, therefore our previous patch is no longer needed.

* [cairomm] Support MSVC2022 (microsoft#23903)

Manually add ed1ce9a630b375b0f43435e34fbe690eb8276178 from upstream,
which prevents MSVC 2022 toolchains from being overridden by the
meson port file, resulting in corrupted binarycache metadata

* [cairomm] update version registries (microsoft#23903)

* [cairomm] add license (microsoft#23903)

* [cairomm] regenerate license registry (microsoft#23903)

Co-authored-by: Schaich <[email protected]>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet