chore: arm linux should work

[dzmitry-lahoda]

• fixed all system check - do not export non existing attrs (no system)
• made 0.8.23 default
• used official rfc formatter and formatter all files
• update list input as it changed its hash (bug fix in place was made by solc people - crazy)
• fixed flake attribute exports warnings
• make sure on recursion in overlay
• ported source build to 8 23 and started templating (seems many changes wil be neede as it goes later versions)
• made error to be soft landing

[dzmitry-lahoda]

@hellwolf so it works, so I did not done template, if you will have time to template - would be awesome.

templating C++ sources good examples are in poetry2nix.

not clear for me how to generate full static binary file, as need one by one download, not really maintainable. likely only you can.

[hellwolf]

Thanks @dzmitry-lahoda !!

That's a lot of changes to review, give me some time.

~~What autoformatting did you use? Going forward, I should setup the same.~~

silly me, I just read your comment. and I am setting up the nixfmt-rfc-style too, now.

[hellwolf]

Hi,

Thanks again for the inspiration.

I merged the change I did myself https://github.com/hellwolf/solc.nix/pull/7, which includes your changes:

• [x] fixed all system check - do not export non existing attrs (no system)
• [x] made 0.8.23 default
• [x] used official rfc formatter and formatter all files
• [x] update list input as it changed its hash (bug fix in place was made by solc people - crazy)
• [ ] fixed flake attribute exports warnings
• [x] make sure on recursion in overlay
• [ ] ported source build to 8 23 and started templating (seems many changes wil be neede as it goes later versions)
• [x] made error to be soft landing (?)

I will further incorporate your changes and additional cleanups:

• More code comments to make contribution easier.
• Check how to include your expression for building from source.
• Fix the rest of the TODOs

[dzmitry-lahoda]

Check how to include your expression for building from source.

This would be awesome. It will make ultimate solution when there is no binary, just try build it. i guess that is main point.

made error to be soft landing

this is about do not throw, but just do not generate attribute (so it will just not find attr in consumer).

make sure on recursion in overlay

I got recursion somehow with flake-parts consumer. So imho better do explicit parameters passing in instead of pkgs, look cosmos.nix for example.

ported source build to 8 23 and started templating (seems many changes wil be neede as it goes later versions)

latest nixpkgs is 8.21, I ported it to 8.23. I see that after 8.23 there are more changes in cmake. so need some flex system for CMAKE FetchContent override. So can start from 8.21 and 8.23 difference easy.

What can I do to help making these in master sooner than later? :)

[hellwolf]

I fixed the infinite recursion issue in main directly. But I also have a different issue in my local NixOS config using it. I will be fixing it asap this week!

[hellwolf]

https://github.com/hellwolf/solc.nix/pull/9 merging:

• CI to test ubuntu-latest, macos-12/13/14.
• Make solc 0.8.23 default.

[hellwolf]

I also realized that a deeper refactoring to use list files from https://github.com/ethereum/solc-bin/ would be better than maintaining my own lists.

[hellwolf]

I will checkout the "ported source build" expression you made.

I am not sure I would want to maintain that in this project yet, to be honest.

[dzmitry-lahoda]

I am not sure I would want to maintain that in this project yet, to be honest.

You mean source version build or solc.nix?

For first, build for existing version will not fail, so maintenance only where source is plugged as fallback for binary, which is 2 lines with // and callPackage. Build itself is static, so it will work all the time without maintenance. Our company will migrate to new version, will PR add newer versions of source (8 25 and 8 23 could be built from source).

If second, ask if nix-community wants to maintain it and move to nix-community org. So these people I am pretty sure are on source version of things. But as you will look nixpkgs, it actually does both, source for linux and binary for mac. So you approach is good. nix-community as org can add more reviewers than only you too (technically problems of own project is that owners of single person repo are single).

[dzmitry-lahoda]

for example request for recently moved project

https://github.com/orgs/nix-community/discussions/835

[dzmitry-lahoda]

@hellwolf anyway, when you decide stop, and ok with having from source fallback in place, i will send new PR for that

[hellwolf]

@hellwolf anyway, when you decide stop, and ok with having from source fallback in place, i will send new PR for that

Thanks again! I an bit slow at the moment, will look into it later this week.

I think I am leaning towards maintaining it indeed, though I wish a bit more clarity in nixpkgs community how to deal with "core" v.s. "contrib" packages.

[dzmitry-lahoda]

I am not nix community :) , so for sure never seen multiversion packages in nixpkgs. All multi version I saw were in nix-community repos (or repos of some orgs like cosmos.nix for example). Nixpkgs seems tracks latest stable release compatible with all other core pacakges in nixpkgs release.

[hellwolf]

Is " ported source build to 8 23 and started templating (seems many changes wil be neede as it goes later versions)" the remaining thing to address in a new pull request?

I am happy to get something like this merged, my 2cents: since this project includes all versions of solidity, would it be a good idea to version the solc build expression too? For example, mk-solc-from-source-0.8.23, and perhaps 0.8.24 works the same so that the 0.8.23 will be reused over time.

[dzmitry-lahoda]

thanks, will open new PR for source.

will do 21,23. 24 and 25 got some changes (replaced json) - if no deps of deps issues - will add. if not - will wait to nixpkgs to catch up.

[dzmitry-lahoda]

no worries, i am still target to follow up on this, so i guess to optimize, will do it when out team decides to move to next version of solc.

[msooseth]

Hi @dzmitry-lahoda is there an update on the way? I'd love to have arm :)

[hellwolf]

fwiw, I should switch the manually maintained list to https://github.com/ethereum/solc-bin/ instead. And if we make any progress on arm solc builds, ideally, it should be an upstream PR there too.