Add Travis (and Kokoro?) build for Windows #631
Comments
|
Absolutely, Yes. I started working on it and then got stuck with the requirement for tcl for windows. It was a while back and might have gotten stale. Related issue - https://github.com/alainmarcel/UHDM/issues/229 |
|
We have a basic windows CI support working. However, we are running into some issues.
Any assistance in identifying the root causes and/or fixing these issues or sharing any pointers helping us do it is highly appreciated. |
|
Maybe @umarcor could help us move to GitHub actions here? |
|
I tried creating a GitHub Actions workflow: https://github.com/umarcor/Surelog/blob/ci/add-gha-workflow/.github/workflows/test.yml However, I'm working on Windows, and it seems that this repository contains several files which have the same name but with different capitalisation: https://github.com/umarcor/Surelog/commit/752b17dfd2d9c0a014f50408036375ffdc49e54f. That's unfortunate, because it produces many conflicts when trying to rebase commits. On the other hand, when cmake is executed, the following error is produced: Hence, it seems that an issue is coming from a submodule. |
|
Apart from that, checks in https://github.com/alainmarcel/Surelog/commits/master show that GitHub Pages is being used, but https://alainmarcel.github.io/Surelog/ seems to be empty. There is no |
|
For the missing submodule files, did the git submodule update --init --recursive |
|
@hs-apotell for the tests that have very few errors compared to Linux, is not doing its job properly on Windows (count the lines). |
|
@hs-apotell one of your Gold files is actually obsolete: |
|
https://github.com/anadishukla/Surelog/blob/master/.github/workflows/cmake.yml Here's our attempt to get Unix build working with Github actions. Something very weird happening. The process rebuilds everything between each command and so ends up taking over 90 minutes before it ultimately fails. Could someone more experienced with Makefile do a quick review of the changes in here - https://github.com/anadishukla/Surelog/blob/master/Makefile |
@umarcor Yes but all those issues are in tests and we haven't yet been able to build successfully to stumble into this issue.
@alaindargelas There is no solution for duplicate name problem for the platform. The files just have to be named differently. Case difference alone is not acceptable on Windows.
@alaindargelas Appreciate the input. We had just started looking into this earlier today.
|
|
Most builds are IO bound. Have we tried moving away from Makefile and using Ninja instead as the build generator option for Linux? The later is supposed to be capable of building in parallel so we should see noticeable improvement in build times - at least, in theory. |
|
For reference, here's the list of files that would need to be renamed. They are all part of Yosys tests. |
|
Just submit a PR and delete them.These files are of no use for Surelog regression.
On Thursday, October 15, 2020, 11:59:49 PM PDT, HS <notifications@github.com> wrote:
For reference, here's the list of files that would need to be renamed. They are all part of Yosys tests.
third_party/tests/YosysTests/misc/scripts/select_%C.ys
third_party/tests/YosysTests/misc/scripts/select_%M.ys
third_party/tests/YosysTests/misc/scripts/select_%x_%D.ys
third_party/tests/YosysTests/misc/scripts/select_add_A.ys
third_party/tests/YosysTests/misc/scripts/select_add_A_eq.ys
third_party/tests/YosysTests/misc/scripts/select_add_A_less.ys
third_party/tests/YosysTests/misc/scripts/select_add_A_lesseq.ys
third_party/tests/YosysTests/misc/scripts/select_add_A_more.ys
third_party/tests/YosysTests/misc/scripts/select_add_A_moreeq.ys
third_party/tests/YosysTests/misc/scripts/select_one_elem_for__C.ys
third_party/tests/YosysTests/misc/scripts/select_one_elem_for__D.ys
third_party/tests/YosysTests/misc/scripts/select_one_elem_for__M.ys
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
@alaindargelas, my bad, submodules were not being cloned recursively. I fixed that yesterday but then some mirror availability issues (unrelated to Surelog) prevented the CI from running: https://github.com/umarcor/Surelog/runs/1262771362?check_suite_focus=true#step:4:21. Fortunately, it's working now: #845 https://github.com/umarcor/Surelog/runs/1264504759?check_suite_focus=true
@hs-apotell see #845 |
@hs-apotell, I could not find the sources of the current Windows CI procedure. Are those public? My approach on GitHub Actions is using MSYS2. That'll soon be the default |
@umarcor We were still attempting it on travis. Here's the last updated revision - https://github.com/anadishukla/Surelog/blob/master/.travis.yml and here's the last unsuccessful run https://travis-ci.com/github/anadishukla/Surelog/builds/189897381 We were having issues with timeouts for linux builds and test failures for windows. |
Interesting. In GitHub Actions Linux builds seem to finish in 30-35 min: https://github.com/umarcor/Surelog/actions |
|
@umarcor I have also been playing around with Github Actions and here's my attempt at it. I just compared my attempt with yours and I don't see any meaningful differences and yet my attempt doesn't succeed. In all my attempts so far, every make command ends up rebuilding the whole source code again. And, after ~90 minutes it just fails. Here's the link to the most recent attempt - https://github.com/anadishukla/Surelog/actions/runs/311323253 |
|
@hs-apotell, what's the motivation for the following?
I think that the only relevant difference is https://github.com/anadishukla/Surelog/blob/actions/.github/workflows/cmake.yml#L16-L17. Likely a different version of cmake is used.
|
|
@umarcor I have minimal CI experience and literally zero on Github Actions itself. I have merely been following working examples to model mine. Some of it is mere desperation in trying to narrow down what's wrong. As it turns out setting the working directory is the problem. Between the following two runs - the only major difference is the one that succeeds doesn't have the working directory set. This specific line was in the default CMake yml file generated by Github. |
|
@hs-apotell, conversely, I have experience with CI (Travis and GitHub Actions), and I help maintain CI in several repos, and I have migrated a few projects from Travis to Actions. However, I know nothing about Surelog, neither the dependencies nor the build procedure. I believe we can help each other!
That is really unfortunate, because setting the working directory is typically not required at all. actions/checkout takes care of cloning and setting the active directory. Anyway, the linux build seems to be solved #845. Let's focus on Windows. Did you succeed in building/using Surelog locally on Windows 10? |
Yes and No. The build itself succeeds but the tests fail. If you deliver on the CI, I am happy to go back to my happy world of programming and debugging :) I can focus on fixing the tests for windows. I have been working off of a fork of Surelog - https://github.com/anadishukla/Surelog |
|
Since the default
As you see, it fails at: Any guess? In https://github.com/anadishukla/Surelog/blob/master/.travis.yml, you seem to be using choco and visualstudio instead of GCC/clang. Is that the toolchain you tested locally? |
Add an environment variable "NO_TCMALLOC=On" (or, optionally -DNO_TCMALLOC=On for cmake command line). We have kept this turned off for Windows for now.
Visual Studio + Ninja is what I have tested locally. Choco is just for installing dependencies which I am not doing locally - only for travis. For travis we were attempting to build it under MinGW bash shell (Git bash shell, to be precise) and we have verified locally that the builds do succeed in this environment. For Windows, the preferred compiler would be VS/cl. Longer term, we would want to switch to using clang for all platforms (low on the long list of wishes). Also, ideally we would switch to using Ninja for ubuntu builds as well to take full advantage of parallel builds. Also, we had to make a few changes to Makefile in the repository to keep the commands compatible across platforms. Check the file https://github.com/anadishukla/Surelog/blob/master/Makefile. In summary, remove the assumption that cmake is using Makefile as generator. |
|
This is as far as I could get without futher modification in the codebase: https://github.com/umarcor/Surelog/runs/1266974896?check_suite_focus=true. I will keep Windows CI on hold until support for Windows is merged upstream. |
|
The default cmake generator on Windows is Visual Studio and the Makefile is not authored to account for it. That was the reason to modify the Makefile as I mentioned in my earlier comment. You will need the Makefile here https://github.com/anadishukla/Surelog/blob/master/Makefile to get past the current error. Give me next 24 hours and I will have a more complete solution with tests ready for CI support. |
@hs-apotell, yet, previous runs using VS were going further than yesterday. That was surprising for me.
As said, I would need instructions about where to get those dependencies and where to extract/install them. Setting the envvars alone is likely to fail. Nevertheless, on MSYS2/MINGW64 most of the dependencies are installed through the package manager. Hence, cmake, make and swig are already available in the PATH. Java was explicitly added too (as we discussed above). Now, I added the following: export CMAKE_GENERATOR=Ninja
export CC=gcc
export CXX=g++
export NO_TCMALLOC=OnIt runs for ~9min before failing: https://github.com/umarcor/Surelog/runs/1287140321?check_suite_focus=true#step:7:1389
What's the purpose of this step?
See https://github.com/umarcor/Surelog/blob/ci/gha-windows/.github/workflows/test.yml#L79 |
@alaindargelas, the Linux job in GitHub Actions is equivalent to the However, building on Windows was not tested/supported until a few days ago, and there is no documented procedure for installing the dependencies, which I could find. That's why trial and error is required, as it allows us to iterate. Precisely, I am unsure about the following:
My proposal is to use MINGW64's GCC or LLVM/clang, and all MSYS2 packages, instead of installing each dependency from a different source. That will allow to rewrite the Windows build procedure as a PKGBUILD build file. That file can be used for testing and also for providing pre-built packages that users can install.
Would you mind pointing me to that description? I could not find it. |
@hs-apotell I have no preference. If VS is what you want to use, that's ok. However, then the list of sources to get dependencies from needs to be documented. Conversely, using MSYS2/MINGW64 should allow to mimic the workflow on Linux: make, gcc, cmake... All should behave almost as in a POSIX compatible environment/shell. |
|
I would like to say that supporting the Microsoft Visual C++ compiler is a "nice to have", while the open source compilers on Windows are a "must have". |
|
In the spirit of general consensus, this is what I tried today locally.
None of the above succeeded. Each of them had different issues. Before I invest more time into this, what is the preferred environment we wish to support. I can provide more details on each of them if interested. @alaindargelas The specific issue I run into with building Visual Studio solution directly is that it needs @umarcor Here's the last attempt on building for Windows on Travis which was building successfully until running out of time during regression tests.
@umarcor Regarding the specific error in your last attempt on GHA, I can't seem to reproduce this issue locally. I always got past that step. However, I still haven't managed to get a successful build under MSYS with any combination of compilers and generators.
@umarcor source_bat.bash was pulled from here. This step is required to setup all the necessary VC related environment variables in Gitbash console. You can find more information about this in the Travis build mentioned above.
I already did it here. Here's the environment variable I had to source and then run the following commands.
I tried MinGW64 + GCC locally and didn't have much luck. I will spend more time to see if I can get a successful build here.
For Windows, VS will be preferred development environment and cl will be the compiler. We have projects dependent on Surelog (and many other public repos) and they all come together in this environment. Pulling one out, building and maintaining a whole different environment is neither viable nor sustainable solution. That said, I am more than happy to assist getting multiple such development environment working. Clang is probably the most desired compiler because of it being available on all our supported platforms and is also supported on all the default development environments across these platforms.
That is exactly what I thought I did with providing the dump of environment variables and the build steps. In fact, we had this nearly working on Travis with few gotchas -
There is no mandate. This is the environment we had it working locally and so the hope was that it would be easiest to replicate on Travis (and now GHA). The recommended environment i.e. VS + CMake + Ninja + cl is the default on Windows. Most windows only developers aren't necessarily familiar with MSYS or MinGW.
+1 to that. We were taking the easiest way out to have a CI system. We chose to replicate what we had working locally. |
I think we want to support MINGW64 + GCC, and some other build with VS and without any MSYS2 package. I would consider MSYS out of scope.
I now added two jobs. One based on MSYS2 and another one using chocolatey.
I see... Is using a bash shell a requirement? I would expect to use cmd o powershell instead. As said, the shell in Git for Windows (Gitbash) is really not meant to be used or relied upon. The proper way of using that bash is precisely using MSYS2's MINGW64, which is what the other job is about.
My bad. I thought that the quote was written by Alain, and that he was referring to some other description apart from yours.
Thanks.
At this point, I think we agree on having two builds. One based on VS, which does not depend on MSYS2 at all. And another one based on MSYS2, which should not depend on any external package apart from Java.
I thought you had installed dependencies by using the respective installers/packages. If done through chocolatey, that's straightforward. Sorry about the misunderstanding. See https://github.com/alainmarcel/Surelog/blob/c6c9e48c3998842a731f725d1efa289c88d55750/.github/workflows/test.yml#L125-L164. |
|
A little progress today. At least I know why the build is failing now. On MinGW, pacman install version 4.x.x of Swig. Surelog needs version 3.x.x. Online pundits claim there is no way to downgrade or to pick a specific version of a package using pacman. I don't want to believe that but again too many seemed to be claiming it to be true. So, how do we proceed forward? @umarcor Here's my environment setup and this seems to work (assuming you can install the specific version of swig on GHA). This is for MinGW + GCC. Only two programs are referenced from outside - make (coming from msys) and java (installed on host windows) I had to add Here's the output of running Attached is the output of the last run reporting the errors. |
MSYS2 is a rolling distribution, just as Arch Linux. Hence, strictly, a single version of each package is supported. However, some previous versions are available in the data store: https://www.msys2.org/docs/package-management/#installing-a-specific-version-of-a-package-or-a-stand-alone-packages. Furthermore, PKGBUILD files are quite simple bash scripts: https://github.com/hdl/MINGW-packages/blob/upstream/mingw-w64-swig/PKGBUILD. Hence, it is possible to checkout an older version and build it. Anyway, Swig 4 has been around for 2-3 years, and branch 3 seems not to be updated since then. Is it not possible to fix Surelog?
I will try with an specific version of Swig.
I guess you did this in the submodule? Could you have a look at the other job?
That's also using swig 4 (coming from chocolatey), and my guess is that it's also failing because of the missing UHDM compile options you mentioned. |
I found: https://github.com/anadishukla/Surelog/tree/winbuilds |
|
I tried building Swig 3.0.12 from sources and using @hs-apotell's fork of UHDM. Still getting the same |
|
@umarcor @alaindargelas So, I finally narrowed down the root cause of the error during model generation. In fact, it has nothing to do with model_gen.tcl script at all, at least not directly. The error was actually coming from its call to capnp.exe. So, it boils down to missing dll dependencies. capnp is dependent on the following dlls and are required to be in the same folder as the executable (or System32 folder on Windows).
Once I made the files available capnp started working as expected. Now the important question - How to know where the dependencies come from i.e. what files are supposed to be copied and from where? Should this part of capnp project or UHDM or Surelog? Do we know whether or not capnp even supports building/running under MSYS? Another issue is that within tcl scripts all exec commands are branched for windows vs. unix. Under MSYS (or MinGW), the platform reported is windows and we use cmd to execute external processes. We are always going to run into this dependency issue because the executables that are built under this environment have dependencies on files that are known only under this environment. I don't feel like I have all the information needed to be able to successfully deliver a full build under MSYS/MinGW. |
|
@hs-apotell
A possible solution is to use Alternatively,
What about the non MSYS2 approach? |
I don't think this would be a good idea because we might run into conflicting version problem. Surelog/UHDM links to capnp libraries explicitly. It's always a good idea to keep the generated code and the library in sync. @alaindargelas might have a different opinion here.
That was my initial thought too but I couldn't find any relevant help on tcl in this context. I am not sure if identifying MinGW within tcl scripts would be possible. @alaindargelas Do you know of a way to detect MinGW/MSYS environment in tcl? I am also divided on this. I am not sure if this would be a good/stable build environment.
One of the files wasn't even named with the extension '.dll'. It had extenstion '.dll.a'. I am not sure if the process will find the file with that extension. Basically, I just don't know enough about these environment to be sure of how dlls are loaded and what location (and order) are scanned to find them.
That is my next stop. I am moving away from MinGW+GCC and on to MinGW+VC. I am tiny bit more confident about this because I have a full working environment locally. |
|
You can maybe check an " if [info exist env(...)] " |
|
@umarcor Here's the last attempt for MSYS + VC I can't seem to figure out how to ignore the errors when sourcing a script. These are expected errors and need to be ignored. I am likely missing something obvious. Appreciate a little help from Unix experts. I have verified the state of the repo locally and everything builds successfully. |
Well, we have access to the build recipe (https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-capnproto) so we know how to fix capnproto for it to work on MINGW64. Are any of you involved in the development of capnp?
This is the most spread approach, not only for C/C++/Ada projects but also for, e.g., Python packages. For example, Pillow needed to be patched in MSYS2 until v7.2.0. In v8.0.0 MINGW64 is supported upstream. Ruby packages on windows are also tested using MINGW64.
My understanding is that dealing with searching DLLs is a sympthom of a broken build procedure. In MSYS2 all dependencies can be installed through the package manager and are located in default Unix locations. Hence, properly built/installed dependencies can find them. My suggestion would be to pick the existing PKGBUILD file for capnp and adapt it from using the submodule, instead of retrieving sources again. Then, it would be built and installed as shown for swig 3.0.12.
There are several envvars which are expected and some required in any MSYS2 shell: So, either checking
You can append
Unfortunately, I don't think that's an acceptable workflow. Powershell, git bash and MSYS2 are mixed. As discussed above, the purpose of using VS + CMake + Ninja is providing "the default Windows toolchain", for those developers who are not familiar with MSYS2 o MINGW. If either Git Bash or MSYS2 are used, then we'd better make the build plumbing understand MINGW64 (see https://github.com/hdl/MINGW-packages#development). The most alarming lines are the following: This is an absolute no go. It is explicitly unsupported and the author/maintainer of Git for Windows told GitHub maintainers NOT to use it. This is why it is to be removed as the default Moreover, adding Git for Windows' MINGW64 binaries to an MSYS2 shell is looking into DLL issues. In fact, Which tools from There is a make in the MSYS2 shell used in step "Build". Why is it necessary to install a different version through chocolatey? Many Python packages need to be patched for them to work on MINGW64. That's why they are available as pacman packages. Hence, using an external Python is not recommended. There might be path conflicts. Overall, you can use option path-type (https://github.com/msys2/setup-msys2#path-type) for making all the host tools available in the msys2 shell. But I'm afraid it might be worse... IMHO, in the non-MSYS2 workflow, "Setup MSYS2" should be removed, the default shell should be set to powershell and steps "Build" and "Test" should be adapted accordingly. Using powershell, the bat file would be sourced without further issues. All the tools would be available in the PATH, because the shells are not isolated by default (which MSYS2 shells are). My only concern is how are cmake and ninja expected to be used without the Makefile. |
The issue here is that we are invoking P.S. This is a not a very good solution to the problem since there is absolutely no restriction on what environment variables might be set. There is a small chance that this might fail in future.
I already tried all the obvious. Adding that
I didn't think so either. I was in the impression that MSYS was a must and so I was just trying to get something functional first in that environment before making a judgement call. Given that powershell is an option, that surely adds potential new solutions.
This is required for tclsh. I haven't found a choco package for tcl. I could either install it manually or use the one that exist already on the machine. Unfortunately, even MinGW doesn't include tcl binaries.
Remanent of trial and error.
Done and here's the first successful run. I tried to make things work with powershell but it got too complicated. I didn't find any workflows examples on Github public repositories using solely powershell. In fact, I found a number of places where the comment read to mean that running the vcvars in powershell is a pain. Everybody seemed to be falling back to
CMake and Ninja aren't dependent on Makefile. The use of Makefile is much like a batch fiel and nothing more. Make is not a requirement for Windows (and neither for unix, if switched to Ninja). It is used as a wrapper around CMake commands. For CI we could make always forgo Make and call the CMake commands explicitly. |
|
First complete build on Windows using cmd. All steps completing, not successfully though. Quite a few regression tests are failing because of wildcard command line args. This feature is not cross-platform compatible. |
|
@umarcor Could you please look into this workflow. As per the documentation (and examples on Github) I am updating the GITHUB_PATH but this doesn't seem to be working. https://github.com/anadishukla/Surelog/runs/1302073363?check_suite_focus=true |
|
Wilcard should be replaced by the file list expanded.
On Sat, Oct 17, 2020 at 1:12 PM HS <notifications@github.com> wrote:
@umarcor You are good to go. With #849 change locally Windows builds successfully. I have provided detailed description of my environment as well.
@alaindargelas #849 lists a few regression test failures which seems logical errors in code and not just platform differences. Could you please take a moment to either diagnose yourself or provide some direction to proceed. Let me know if you need full log files to assist.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Did you mean in the input |
|
No, just expand manually to the files present in the directory. Most cases have explicit file lists, only a few have wilcard, replace those with the actual file names
On Sat, Oct 17, 2020 at 1:12 PM HS <notifications@github.com> wrote:
@umarcor You are good to go. With #849 change locally Windows builds successfully. I have provided detailed description of my environment as well.
@alaindargelas #849 lists a few regression test failures which seems logical errors in code and not just platform differences. Could you please take a moment to either diagnose yourself or provide some direction to proceed. Let me know if you need full log files to assist.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
@umarcor Feedback welcomed on this PR https://github.com/alainmarcel/UHDM/pull/362 |
I believe this is the proper solution.
Variables such as
This is really unfortunate. Isn't there a "regular" tcl installer for windows?
That sounds sensible. Note that I changed the approach in #847. Instead of trying to run shell commands in the workflow, I created a proper PKGBUILD file in subdir On the other hand, the problem we are hitting again and again is UHDM. Hence, I'll focus on creating a PKGBUILD file for UHDM, which will allow to then build it in here, as we do with swig. However, UHDM has specific dependencies, so we might need to go further down the chain. Precisely, capnp is patched in MINGW-packages, which means that it is unlikely to work by building it as a plain dependency of UHDM. Let's handle that in #363, and we'll come back here once UHDM is done.
By default, MSYS2 has a clean environment (PATH). Although inheriting the PATH is possible, it should be avoided. Writing to |
Not really. There are dropbox builds available and I was initially using it on UHDM Travis builds. It just so happens that the website disappeared a few days later leaving our builds broken. For what little I know about TCL, the support for the language isn't very great on Windows. It very much seems an after thought.
Will leave it up to @alaindargelas to decide what direction he wants to take. Makefiles on Windows though supported have lots of cons. A typical makefile written without paying attention to the platform is unlikely to work out of box on Windows. I already had to fix a number of issues, for instance, use of
I will leave all those beautiful stuff for some one else to figure out. Getting every change verified on a machine that isn't mine is how far I take it. I am sure you will have fun with the rest. |
I propose keeping the |
|
Both UHDM and Surelog repositories now have GHA support including regression. Configurations include -
|
Originally posted by @alaindargelas in https://github.com/alainmarcel/Surelog/issues/239#issuecomment-658534307
We should have CI running on Windows so that we don't break the Windows build accidentally.
The text was updated successfully, but these errors were encountered: