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

Cygwin, FreeBSD and Long Doubles #729

Merged
merged 11 commits into from
Feb 15, 2022
Merged

Conversation

mborland
Copy link
Member

@mborland mborland commented Jan 3, 2022

Consolidates #727 and #728 to allow for other CI fixes before merge.

@NAThompson
Copy link
Collaborator

@mborland , @jzmaddock : I noticed that we haven't done a standalone for 1.78 yet; would it make sense to use this fix to tag a standalone?

@jzmaddock
Copy link
Collaborator

I noticed that we haven't done a standalone for 1.78 yet; would it make sense to use this fix to tag a standalone?

We could do, there are quite a few cygwin-related CI failures showing though. Some are trivial limits-set-to-low, others look a bit more worry-some at first glance.

@mborland
Copy link
Member Author

mborland commented Jan 4, 2022

@mkoeppe Does SageMath use the standalone version of Boost.Math? If not I think we are safe to cut the standalone release without this.

@mkoeppe
Copy link
Contributor

mkoeppe commented Jan 4, 2022

@mkoeppe Does SageMath use the standalone version of Boost.Math?

No

@ckormanyos
Copy link
Member

Hi Matt (@mborland) this is not directly related to the exact build issue...

Nonetheless, I've been wondering if the explicit use of the commit filter in the YAML script is still helpful or up-to-date or needed. My understanding is that GHA now comprehends the [ci skip] expression in commits. If we agree to establish use of [ci skip], could we remove these commit filter artifacts? Or do you think we need them for another process that I'm not thinking of.

@mborland
Copy link
Member Author

@jzmaddock Can you take a look at this? The error rates that Cygwin has for the special functions are in line with what MinGW produces so I don't see any serious problems there. I think for our purposes we can consider Cygwin as having appropriate long double support.

@mborland
Copy link
Member Author

Ping @jzmaddock

@jzmaddock
Copy link
Collaborator

Looks good to me, just out of interest, what's the issue with the tests that are disabled for cygwin?

@mborland
Copy link
Member Author

Looks good to me, just out of interest, what's the issue with the tests that are disabled for cygwin?

They all require big object support which still failed when the flag was passed due to a lack of support.

@jzmaddock
Copy link
Collaborator

They all require big object support which still failed when the flag was passed due to a lack of support.

Ah, yes, GCC's object size limit on windows is super annoying... merging.

Thanks for this!

@jzmaddock jzmaddock merged commit 20ae7d1 into boostorg:develop Feb 15, 2022
@mkoeppe
Copy link
Contributor

mkoeppe commented Feb 15, 2022

Thanks a lot for working on this!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants