-
Notifications
You must be signed in to change notification settings - Fork 284
Fix cmake build from VS2019 command prompt #5306
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -5,9 +5,17 @@ add_executable(converter library/converter.cpp) | |
|
|
||
| file(GLOB ansi_c_library_sources "library/*.c") | ||
|
|
||
| add_custom_command(OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/cprover_library.inc" | ||
| COMMAND cat ${ansi_c_library_sources} | $<TARGET_FILE:converter> > "${CMAKE_CURRENT_BINARY_DIR}/cprover_library.inc" | ||
| DEPENDS converter ${ansi_c_library_sources}) | ||
| # Convert cmake paths to native paths for Windows builds | ||
| file(TO_NATIVE_PATH "${ansi_c_library_sources}" | ||
| ansi_c_library_sources_paths) | ||
| file(TO_NATIVE_PATH "${CMAKE_CURRENT_BINARY_DIR}/cprover_library.inc" | ||
| cprover_library_path) | ||
| file(TO_NATIVE_PATH "${CMAKE_RUNTIME_OUTPUT_DIRECTORY}/converter" | ||
| converter_path) | ||
|
|
||
| add_custom_command(OUTPUT "${cprover_library_path}" | ||
| COMMAND cat ${ansi_c_library_sources_paths} | ${converter_path} > ${cprover_library_path} | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm afraid this doesn't quite work on windows (not on our CodeBuild machines here); We'd need Frustratingly this isn't showing up as a failure in codebuild due to an unrelated bug in how that build is set up. I've been thinking of changing the build so it publishes the build log somewhere publicly visible at least, but I've note gotten around to that yet.
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure what to do here. The add_custom_command is not my contribution. My contribution is invocations of TO_NATIVE_PATH to get the right path separators on windows so the invocation of cat won't fail. Is the issue that we are using different instances of cat? Maybe you are getting the cat that comes with cygwin that wants linux path separators and I am getting the cat that comes with the git shell that on windows wants windows path separators? Personally, I think that if we get rid of cygwin completely and just build from the native command shell, that is the right way to go.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. On our codebuild jobs we're actually building on powershell, not a cygwin environment. The
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think the natural thing to do is to build cbmc with the natural build environment on windows. I have been trying to get cbmc to build within the visual studio command prompt that is just cmd with all the paths set correctly to run visual studio. Visual studio comes with cmake and ninja. Visual studio can be installed with git and the git shell that gives you access to all the linux utilities you might need. I gave my procedure in the top comment of this pull request. We can simulate this inside an ordinary cmd shell, just run the script vcvars64.bat to set up the environment variables as the visual studio command shell does. Let's stop doing all this crazy stuff to cbmc to build, and just get it to build the right way in the native build environment.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This is exactly what we're already doing. https://github.com/diffblue/cbmc/blob/develop/buildspec-windows-cmake.yml
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Though, as far as I'm aware, this doesn't actually work? I believe this PR is a way towards making this work? Of course, we should discuss each individual change to see whether it's the right/best way to make things work. |
||
| DEPENDS converter ${ansi_c_library_sources_paths}) | ||
|
|
||
| add_executable(file_converter file_converter.cpp) | ||
|
|
||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this really quite does what you want here;
ansi_c_library_sourcesis a list not a single path. Also, without a second argument to store the result in this is just a no-op. The main problem withcaton windows isn't that it doesn't understand forward slashes as path separators, it's that it doesn't exist. On cygwin it'd work fine, but on powershell we'd needGet-Contentand I'm not even sure what the right way to do this oncmdwould be.TBH I think the correct solution here would to be just scrap the cmake bits of this entirely and just change our file converter to read from files passed in as arguments rather than from STDIN, then we don't have to worry about cross platform quirkiness. I'll have a look at that today, then maybe this patch won't be necessary at all?
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I may be abusing the semantics of TO_NATIVE_PATH, but the effect of this invocation is to replace the path separators. The second argument is in the second line below your comment.
I like the idea of scrapping cat. The cbmc project has been getting it from various ports of linux utilities. The cbmc build has traditionally been getting it from cygwin. I am trying to avoid cygwin, and I'm using the version that comes with the git shell that is part of the visual studio installation git installation. The problem is that different ports do different things with path separators.
Whatever you come up with, I'm going to apply the patch to the 5.12 distribution to build it. I'm trying to build distributions patches of 5.12 for the major repositories (homebrew, debian, windows). I'm trying to set up github actions to automate this for head versions.