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

Add support for no_std #63

Merged
merged 1 commit into from
Nov 7, 2024
Merged

Conversation

waywardmonkeys
Copy link
Collaborator

This doesn't support the scale or render features yet as that needs an update to zeno and yazi.

@waywardmonkeys
Copy link
Collaborator Author

If this lands, I can revise #61 to deal with no_std.

@waywardmonkeys
Copy link
Collaborator Author

I should add a lot of CI to this repo, including for no_std.

@waywardmonkeys
Copy link
Collaborator Author

Added a check for no_std on x86-64-unknown-none.

I didn't use a 32 bit target because the one I chose didn't work due to not having an AtomicU64.

@waywardmonkeys
Copy link
Collaborator Author

I think it'll be best if #61 lands first and then I'll revise this some to support scale, render and fix some associated warnings.

@xStrom
Copy link
Collaborator

xStrom commented Nov 5, 2024

Swash not having no_std support is blocking Parley from having it, so we should really get this landed. I do agree though that #61 makes sense to land first, because the no_std support has changed in those deps as well.

@waywardmonkeys
Copy link
Collaborator Author

@dfrg I've updated this PR to not have merge conflicts ... it gives no_std support but not for the scale or render features. This is still a breaking change since it requires that someone use either the std or libm features, compilation without them won't work.

@xorgy
Copy link
Collaborator

xorgy commented Nov 6, 2024

@waywardmonkeys

I didn't use a 32 bit target because the one I chose didn't work due to not having an AtomicU64.

See #69

@dfrg
Copy link
Owner

dfrg commented Nov 6, 2024

oops, I seem to have merged these in the wrong order causing a merge conflict (did the dep updates first)

@waywardmonkeys
Copy link
Collaborator Author

When I am awake today, I will update this so that it is fully no_std now that the deps update landed.

@waywardmonkeys
Copy link
Collaborator Author

@dfrg This is updated now. If you land #70 before this, I'll add some 32 bit no_std CI checks ... otherwise, can do that after these both land.

Copy link
Owner

@dfrg dfrg left a comment

Choose a reason for hiding this comment

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

no_std support has been a much requested feature since this crate was released and I really appreciate the work to get it done.

LGTM

@dfrg
Copy link
Owner

dfrg commented Nov 7, 2024

@dfrg This is updated now. If you land #70 before this, I'll add some 32 bit no_std CI checks ... otherwise, can do that after these both land.

I just merged #70 so I’ll leave it up to you whether we do the 32-bit checks here.

@waywardmonkeys
Copy link
Collaborator Author

@dfrg This is updated now. If you land #70 before this, I'll add some 32 bit no_std CI checks ... otherwise, can do that after these both land.

I just merged #70 so I’ll leave it up to you whether we do the 32-bit checks here.

Done. I was distracted by trying to fix Zeno's CI and wasn't looking at emails.

@dfrg dfrg merged commit 3c18106 into dfrg:main Nov 7, 2024
8 checks passed
@waywardmonkeys waywardmonkeys deleted the add-no_std-support branch November 7, 2024 02:36
github-merge-queue bot pushed a commit to linebender/parley that referenced this pull request Nov 7, 2024
To really get no-std support in parley, we need to land dfrg/swash#63.
But I believe I've done everything else that's necessary, in both parley
and fontique. One can test the build by patching Cargo.toml to use the
working branch for that swash PR, and modifying parley/Cargo.toml to
specify swash/std or swash/libm as appropriate. If we decide to land
dfrg/swash#63 before landing this one, then I can make the latter
modification to parley/Cargo.toml before merging this PR.

Some of my changes, e.g. unconditionally using `alloc::vec::Vec`, are
designed to minimize the amount of noise when searching the whole source
tree for "std".
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.

4 participants