-
Notifications
You must be signed in to change notification settings - Fork 437
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
fix msys2 windows build so the windows apps support utf-8 file paths. #668
Conversation
Ahh, much simpler :) . Modifying the MSYS2 installation during build doesn't sound very "nice" though. Should we perhaps put it in the setup instructions/ |
Yeah, what I'd like to be able to do is modify src/shell/CMakeLists.txt like this:
this works, it does invoke windres and compile the app manifest resource, and it tries to link it but then I get this compile error:
Even though the resulting lean.rc.obj is byte for byte identical to the default-manifest.o. So it seems I'm hitting msys issue #454 which claims to have been fixed in a gcc-patch, but I'm not seeing it. That's why I'm replacing the system installed default-manifest.o. And I want to do it during build and not in the github workflow because I want it to also work for devs setting up their own msys environment without adding any addition faffing about. The In my little cmake test app clang builds work fine and it links my custom lean.rc.obj no problem. So if we can fix the bug in stdlib.make (or is it in leanc) then switching to clang solves the default-manifest.o problem... |
You can look at the executed cmdline using
Is this with clang? The cmdline you posted in that issue does not specify a compiler. |
Cool, also making progress here: msys2/MINGW-packages#9603 (comment) so it seems we may be able to get updated version of msys that will remove the requirement on patching the default-manifest.o file... So I won't merge this until I get that resolved. |
Ok, VERBOSE=1 helps, this is the log output, we see it is invoking "leanmake"... which I think is in turn invoking "lean.mk"...?
|
Ok, I pushed new changes to stop modifying default-manifest.o and this part of the build fails eroneously:
saying:
something about stdlib.make is getting confused by the contents of |
Yes, you need to replace the |
Btw, you shouldn't need to change stage0/ here. It has its own cmake files, so as long as a change isn't needed in the Lean executable that builds stage 1, it is sufficient to change src/ only. |
well theoretically someone could clone "lean" into a unicode path, then all hell would break loose in msys when using the stage0 version of lean.exe. |
@lovettchris We try to avoid updates to stage0 in PR's since they require extra work when merging. For example, we often have to manually rebase, build, and replay all stage0 updates in a PR because they are out of sync with other changes made in the master branch. I am not concerned about the scenario you have described. It will be corrected later when we perform the regular update stage0 operations. |
Ah, I missed your semicolon fix before, I found another way to fix that using COMMAND_EXPAND_LISTS. |
so that's what I was wondering, what is the process for updating stage0? Do we have to keep it in sync always, or is it done in separate PR's. I've definitely seen PR's that do both in one PR. Not sure how I see me keeping it mirrored causes extra work though? |
Ooh, nice! |
You should only update stage 0 in a PR if it is necessary for the PR to build. All other changes will find their way automatically into stage 0 eventually after merging (usually in a matter of days) when it is updated for some other change. |
ok, I undid changes to stage0 although I still don't see how that creates merging problems unless there are pending pull requests that are changing those exact same lines in the CMakeFIles.txt file. git merging is typically pretty good. I understand you can't have the makefiles diverge because that makes updating stage0 harder, but I was not doing that I was mirroring the files just like you would in a bigger stage0 update... am I missing something about git here? |
Manually copying stuff into stage 0 should already be considered an advanced operation, the intended way is to always go through |
Basically stage0/ should be considered a single binary blob, which in fact is the case in other bootstrapping schemes, and which we tell Git and GitHub to do so in the |
Ok got it, it is just "being careful" process then, sounds good. We should write this down someplace... do we have docs for team members somewhere? |
We have some documentation here https://github.com/leanprover/lean4/blob/master/doc/make/index.md, but we definitely need more. |
Maybe I should start a 'dev' folder that includes coding guidelines and tips & tricks, etc... |
Yes, a |
I'll do the 'dev' doc updates in a separate PR. This PR is ready for approval. |
Hmm, did the |
Could you also add a test case, e.g. adding output to a Unicode file path to |
We should also make sure |
good idea, will do. |
I guess so, I was afraid of that as there was a merge conflict on this line of the cmake. |
…tf-8 encoded files where utf-8 is also used in the file name.
…nto clovett/windows-utf8
Tracking mathlib commit: [39af7d3bf61a98e928812dbc3e16f4ea8b795ca3](leanprover-community/mathlib3@39af7d3) Co-authored-by: Scott Morrison <scott.morrison@gmail.com>
fix: utf-8 file paths on Windows.
You can now do this on windows:
Notice that the file path can contain unicode chars and the arguments can be passed as utf-8.
Without this fix you get this:
where
Hello.lean
contains