Skip to content
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.

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

Use gcc-9 for macOS builds #617

Closed
wants to merge 1 commit into from
Closed

Use gcc-9 for macOS builds #617

wants to merge 1 commit into from

Conversation

smk762
Copy link

@smk762 smk762 commented Mar 8, 2024

Closes #616

Copy link
Collaborator

@dimxy dimxy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@DeckerSU
Copy link

DeckerSU commented Mar 8, 2024

LGTM also, but I need to conduct some tests on Mac, such as a full-sync, and other internal tests before I can give explicit approval. Therefore, it will be labeled as "Under Testing" until I complete all the necessary checks. I strongly believe that we should stop using gcc on Mac and switch to the native clang, as I have already done in the KomodoOcean repository. This is on my to-do list and I plan to open a separate PR for this till the next season. For now, we will continue with gcc@9.

@DeckerSU
Copy link

DeckerSU commented Mar 8, 2024

The compiler changes for Mac mentioned earlier are now available here: #618 .

@TheComputerGenie
Copy link

If the object is to update, why not update to a version that's modern enough to be supported in the future rather than the oldest working but most likely to be disabled version?
8 is no longer supported so move to 9 rather than 10, 11, 12, or 13?
I asked this in another post, but: Is there some logical reason that we observers are missing that justifies not making things for the future rather than so old that no one supports them? [or in this case will soon no longer support them]

@smk762
Copy link
Author

smk762 commented Mar 11, 2024

If the object is to update, why not update to a version that's modern enough to be supported in the future rather than the oldest working but most likely to be disabled version? 8 is no longer supported so move to 9 rather than 10, 11, 12, or 13? I asked this in another post, but: Is there some logical reason that we observers are missing that justifies not making things for the future rather than so old that no one supports them? [or in this case will soon no longer support them]

In some cases, its for backwards compatibility so people using older operating systems which are still supported (i.e. not yet at EOL) can continue use the app/binary etc. Another consideration is resulting required code / syntax changes which the dependency being updated has breaking changes, or triggers a cascade of other deps needing updates or deps being incompatible if one doesnt support the other yet. Resource allocation is also a consideration. If I can change a number in a few files and it works, I dont need to spend hours/days on a while bunch of other changes trying to make it work.

@smk762 smk762 closed this Mar 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants