solidity
solidity copied to clipboard
Attempt to run against newer windows image.
For reference: https://discuss.circleci.com/t/march-2022-support-for-new-operating-system-for-windows-executors-windows-server-2022/43198 and https://circleci.com/docs/2.0/hello-world-windows/#windows-executor-images
Hm... weirdly CircleCI rejects my SSH keys when trying to log into the CI runs here...
Attempt failed. Close?
Attempt failed. Close?
@christianparpart wanted to take this over... we still have to fix this, but that's best done by somebody with a windows setup.
Please take over @ekpyron . I am still busy with other stuff, sadly. But ping me on review, if you don't mind.
So don't close.
Ok, I spent some time looking into the failures via CI SSH now... apparently there's some issues with MSVC and range-v3's sort - which is unfortunate, but I guess we could live with reverting that to legacy iterator style...
The test failures now, I suspect, are probably due to the boost::filesystem changes in the newer boost...
@cameel If you find the time, this here is what I meant the other day with having some issues with the boost::filesystem tests after a boost update.
Today @nikola-matic tried to update Boost and CMake and ran into errors. I haven't had time to look here yet but I just realized that you must have been doing the same thing and looks like that's the case.
So here's what these errors mean: https://github.com/ethereum/solidity/pull/13434#issuecomment-1227665365
In short: looks like Boost 1.78 changed the way paths starting with // are normalized. Either only on Windows or in general. We need a workaround in FileReader to be able to handle these paths the old way on new Boost.
Today @nikola-matic tried to update Boost and CMake and ran into errors. I haven't had time to look here yet but I just realized that you must have been doing the same thing and looks like that's the case.
So here's what these errors mean: https://github.com/ethereum/solidity/pull/13434#issuecomment-1227665365
In short: looks like Boost 1.78 changed the way paths starting with
//are normalized. Either only on Windows or in general. We need a workaround inFileReaderto be able to handle these paths the old way on new Boost.
Yup, I'm not at home so can't link, but look at the 1.78.0 changelog for filesystem, and there are changes for path::lexically_normal and other friends.
@nikola-matic Alright, so if you want to take care of this feel free to put things together into a single PR, s.t. we don't have duplication - for now I'll keep this open, since it has the CI changes - feel free to either take this one over or reproduce the CI changes in the other one.
I think moving CI to VS2022 and bumping our recommendation in the docs is the best choice. We could also have two CI runs, one for 2019 and one for 2022, but I don't think there is much cause for people not to update to VS2022, so keeping it at a single one, i.e. the current one 2022, is fine.
Of course, we somehow need to deal with the boost filesystem issues.
@nikola-matic Alright, so if you want to take care of this feel free to put things together into a single PR, s.t. we don't have duplication - for now I'll keep this open, since it has the CI changes - feel free to either take this one over or reproduce the CI changes in the other one.
I think moving CI to VS2022 and bumping our recommendation in the docs is the best choice. We could also have two CI runs, one for 2019 and one for 2022, but I don't think there is much cause for people not to update to VS2022, so keeping it at a single one, i.e. the current one 2022, is fine.
Of course, we somehow need to deal with the boost filesystem issues.
Yup, I noticed your PR a bit late, so after I fix the boost::filesystem issue, I'll make the CI related changes in my PR (or rather on my branch) as well. So I guess we can even close your PR, or simply wait until my PR's merged, and the just make the necessary CI changes in yours (i.e. leave it as is).
Fine with me either way, so I'm just closing this PR (we'll still have the changes on the branch for later).