Now the installation is extracted to a reusable batch script and install all dependencies, including the ones installed by default on appveyor. This allows the users of the vm to use the script to build their own cygwin to compile the vm without having to look for all needed dependencies.
I am not sure it will work at the first try. I do a PR to let appveyor test it for me. You can view, comment on, or merge this pull request online at:
https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/242
-- Commit Summary --
* Refactor cygwin installation for appveyor. Now the installation is extracted to a reusable batch script and install all dependencies, including the ones installed by default on appveyor. This allow the users of the vm to use the script to build their own cygwin to compile the vm without having to look for all neededs dependencies.
-- File Changes --
M .appveyor.yml (21) A .appveyor_installCygwin.bat (70) M build.win32x86/HowToBuild (3) M build.win64x64/HowToBuild (2)
-- Patch Links --
https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/242.patch https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/242.diff
Hi Cyril,
wouldn't it be better to have the script in scripts with some visible name?
_,,,^..^,,,_ (phone)
On Apr 7, 2018, at 7:59 AM, CyrilFerlicot notifications@github.com wrote:
Now the installation is extracted to a reusable batch script and install all dependencies, including the ones installed by default on appveyor. This allows the users of the vm to use the script to build their own cygwin to compile the vm without having to look for all needed dependencies.
I am not sure it will work at the first try. I do a PR to let appveyor test it for me.
You can view, comment on, or merge this pull request online at:
https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/242
Commit Summary
Refactor cygwin installation for appveyor. Now the installation is extracted to a reusable batch script and install all dependencies, including the ones installed by default on appveyor. This allow the users of the vm to use the script to build their own cygwin to compile the vm without having to look for all neededs dependencies. File Changes
M .appveyor.yml (21) A .appveyor_installCygwin.bat (70) M build.win32x86/HowToBuild (3) M build.win64x64/HowToBuild (2) Patch Links:
https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/242.patch https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/242.diff — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.
I hesitated because the installations of Travis are at the root. I'll do the changes because I wanted to add it there at the beginning and changed my mind to follow travis. I forgot about the visibility problem.
Maybe we should move all of them to scripts/ci/ or a new top-level dir ci/?
It looks good to me, and the cygwin install was performed. I wonder why the build later failed? https://ci.appveyor.com/project/OpenSmalltalk/vm/build/1.0.1240/job/8juaracj...
It seems a good solution. For my part, I have no preference between /scripts/ci or /ci. So I'll do the changes to the PR when a decision will be made.
@nicolas-cellier-aka-nice Maybe variables name conflicted? This seems very unlikely since one is a batch script and the other a bash script but I don't have enough experience with appveyor to totally exclude the possibility.
In my next commit I can add some logs to the travis build script to spot the prolem.
nicolas-cellier-aka-nice commented on this pull request.
@@ -0,0 +1,70 @@
+@echo off + +REM Thi script can takes up to 4 parameters:
Small typo s/thi/this/
@jecisc pushed 1 commit.
16f54a3 Move cygwin installation scripts to scripts/ci/ and change variables names
I moved the script to scripts/ci/ and renamed it. If later the ci/ folder is chosen I can change it.
I also corrected the typo and changed the variables names to be totally sure they do not interfere.
@jecisc pushed 1 commit.
4b7a712 Batch takes the working directory and not the script directory to resolve paths. Correct paths knowing that.
The build buildwin64.64/pharo.cog.spur failed. I launched it locally to check if I can reproduce the problem.
I get the same error locally.
I don't know what can be the error because if I compare this build with a build that passed earlier, the only change I can find is that now cygwin install unzip to be able to also build VMMaker.
See diff here: https://www.diffchecker.com/sAQ7WlFr At the left the build from `Merge pull request #241 from OpenSmalltalk/sista_lowcode_clang_again` At the right the build from `Pull request #242 - Refactor cygwin installation for appveyor`
There is another difference: the successfull build does use the .thirdparty-cache https://ci.appveyor.com/project/OpenSmalltalk/vm/build/1.0.1241/job/jde7286l...
line 5 Cache '.thirdparty-cache' - Restored
Then it just keep the prebuilt library rather than rebuilding it
line 362 cp -f /cygdrive/c/projects/vm/.thirdparty-cache/windows/x86_64/bin/libssh2-1.dll build/vm
Could it be related to this commit? https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/57e68cef046c7309261... See my comment about `THIRDPARTY_TOOLCHAIN` in build.win64x64/common/Makefile.lib.extra
IIUC the CI caches the build of external plugins and it just builds the plugins sometimes. (randomly?)
So, if I restart the build it will pass except if I have another build triggering the recreation of the cache? Should I do that since the problem is not related to this PR?
On Sat, Apr 7, 2018 at 8:15 AM, Fabio Niephaus notifications@github.com wrote:
Maybe we should move all of them to scripts/ci/ or a new top-level dir ci/?
+1. Lovely idea. Succinct and indicative.
_,,,^..^,,,_ best, Eliot
Let's avoid another top-level dir and go with scripts/ci/. But please be aware that the scripts might make assumptions as to where they live. CI should bark anyway at you if you've missed something :) thanks!
@jecisc pushed 1 commit.
92574fe Add curl to default packages to install via cygwin to make VMMAker image building work on windows 10
After getting tired of having to re-run the CygWin setup-x86.exe a few times to install one-more-missing-requirement, I discovered this PR and manually extracted "scripts/ci/installCygwin.bat" from this PR to my system so I could run it manually.
Afterwards doing "cd build.win32x86/pharo.cog.spur; ./mvm" worked like a dream and an hour later the compile completed successfully.
So it seems this is a great initiative. What is holding it up? Can an admin give the CI a bump to see if the error was transitory?
Hi Ben,
On Thu, Jul 12, 2018 at 8:37 AM, Ben Coman notifications@github.com wrote:
After getting tired of having to re-run the CygWin setup-x86.exe a few times to install one-more-missing-requirement, I discovered this PR and manually extracted "scripts/ci/installCygwin.bat" from this PR to my system so I could run it manually.
So should this be mentioned in HowToBuild?
Afterwards doing "cd build.win32x86/pharo.cog.spur; ./mvm" worked like a dream and an hour later the compile completed successfully.
An hour?
So it seems this is a great initiative. What is holding it up?
What's the issue?
Can an admin give the CI a bump to see if the error was transitory?
_,,,^..^,,,_ best, Eliot
Hi,
On 12/07/2018 19:43, Eliot Miranda wrote:
Hi Ben,
So should this be mentioned in HowToBuild?
This will be mentionned after the PR is integrated:
https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/242/files#diff-ac2d0c...
An hour?
When there is no cashes the build of the windows VM can take between 45min and 4h from my experience (Maybe one was on a SSD and another on an HDD)
What's the issue?
The issue is that the CI is broken and only pass because of caches in other PR. With this PR, one of the cache was invalidated and the VM build broke, so the PR was not integrated because the check did not pass.
Maybe it is corrected by now?
Anyway, now there is a merge conflict :(
Can an admin give the CI a bump to see if the error was transitory?
_,,,^..^,,,_ best, Eliot
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/242#issuecomment-404593068, or mute the thread https://github.com/notifications/unsubscribe-auth/AhLyW_cSqykK4M8NEEzlsHl9Gi7uqJSHks5uF4rQgaJpZM4TLHTw.
@jecisc pushed 1 commit.
326b009 Merge branch 'Cog' into cf_useScriptToInstallCygwinWithAllDependencies
On 13 July 2018 at 01:43, Eliot Miranda notifications@github.com wrote:
Hi Ben,
On Thu, Jul 12, 2018 at 8:37 AM, Ben Coman notifications@github.com wrote:
After getting tired of having to re-run the CygWin setup-x86.exe a few times to install one-more-missing-requirement, I discovered this PR and manually extracted "scripts/ci/installCygwin.bat" from this PR to my
system
so I could run it manually.
So should this be mentioned in HowToBuild?
Definitely! Once this PR is merged. The PR includes an update to HowToBuild... https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/242/files
Afterwards doing "cd build.win32x86/pharo.cog.spur; ./mvm" worked like a dream and an hour later the compile completed successfully.
An hour?
Cyril saw similar time, step 5 here... http://forum.world.st/Compiling-the-windows-32-bits- vm-tp5072691p5073200.html I believe most of this time was building Pharo's third-party libs.
cheers -ben
Checks are now green! :)
Any news on this integration?
Can this please be integrated? It seems amendments covered off all comments.
I moved the script to .../scripts/ci/
Actually, I think it might be better located in just .../scripts/ since its useful to anyone manually setting up for local cygwin builds - but don't let that hold up the integration.
Merged #242 into Cog.
@bencoman merged and moved via https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/815be6b5123c2939f26....
Super cool. Thanks @fniephaus.
vm-dev@lists.squeakfoundation.org
-
Ben Coman -
Cyril Ferlicot D -
CyrilFerlicot
-
Eliot Miranda
-
Fabio Niephaus
-
Nicolas Cellier