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
File Changes
Patch Links:
— |
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 <[hidden email]> 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. > — |
In reply to this post by David T Lewis
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. — |
In reply to this post by David T Lewis
Maybe we should move all of them to scripts/ci/ or a new top-level dir ci/? — |
In reply to this post by David T Lewis
It looks good to me, and the cygwin install was performed. — |
In reply to this post by David T Lewis
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. — |
In reply to this post by David T Lewis
@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. — |
In reply to this post by David T Lewis
@nicolas-cellier-aka-nice commented on this pull request. In .appveyor_installCygwin.bat: > @@ -0,0 +1,70 @@ +@echo off + +REM Thi script can takes up to 4 parameters: Small typo s/thi/this/ — |
In reply to this post by David T Lewis
@jecisc pushed 1 commit.
— |
In reply to this post by David T Lewis
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. — |
In reply to this post by David T Lewis
@jecisc pushed 1 commit.
— |
In reply to this post by David T Lewis
The build buildwin64.64/pharo.cog.spur failed. I launched it locally to check if I can reproduce the problem. — |
In reply to this post by David T Lewis
I get the same error locally. — |
In reply to this post by David T Lewis
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 — |
In reply to this post by David T Lewis
There is another difference:
Then it just keep the prebuilt library rather than rebuilding it
— |
In reply to this post by David T Lewis
Could it be related to this commit? — |
In reply to this post by David T Lewis
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? — |
In reply to this post by David T Lewis
On Sat, Apr 7, 2018 at 8:15 AM, Fabio Niephaus <[hidden email]> 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 — |
In reply to this post by David T Lewis
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! — |
In reply to this post by David T Lewis
@jecisc pushed 1 commit.
— |
Free forum by Nabble | Edit this page |