Fingers crossed will report back: just one quesiton:
do you always re-download / git check-out the latest tracked version (master / dev / etc) or the release watcing and updating, downloading of the newer versions have to be done manually each time there is one?
Thanks for all the work!
mhertz wrote:The stable deluge build script, previously builded from latest release tag on git, but was hard for me to find out how to script be automatic between updates, so had to update a variable every time new version came(I think I can now though, like I do with python, but previously had issues when trying). Then I found I didn't even have too, because in deluge, then master branch is latest stable, so latest commit of master branch is last commit of deluge 2.0.3 currently, so that is why I use master in there, but it is in fact stable release.
BTW, I used to use cygwin as didn't have msys2 in beginning as couldn't build gvsbuild in beginning and just used Cas's last build. Anyway it needed forward slashes for patch.exe, hence script uses such still, even though supported in windows backwards way in msys2.
I used a dos notion of program files one place, as was specifically needed, as double quotes didn't work, and tried all things possible, where only that worked, as issue in python function in path with spaces.
Someplaces, because I added %programfiles% to a path for patch, then slashes are mixed, both regular and backwards, but it works still, and so was to lazy to change.
Not important, but some things look strange, but usually isn't an oversight, but just needed, or lazyness from changing old to new.
Also, deluge scripts use %programfiles%, whereas all others do not, for python install, and again was from old times, soon a year ago, where I provided batchfiles to install deluge2, in another thread not of mine, and didn't bothered change, as made no difference in end result and I would need edit 30 lines or so, to change,for no functional reason.
For libtorrent's, I originally tested almost 10 different boost versions, and only one worked for me, so stuck to that, and there's a range of supported boost versions for each branch of libtorrent, and the ones I use are within range, and I also saw suggested by others to be working good for them on libtorrent mailing-list. There's always a bunch of warnings displayed during building those, which you should simply ignore and is normal. If actual error happens, the building will fully stop and not produce any end result I.e libtorrent.pyd, and so if a libtorrent.pyd is produced then it is working. I think I made around 100 runs initially to get those libtorrent's to build to end, as had no experience either with such and depends on combinations used of your used versions of libtorrent, boost, python and msvc. Luckily I got it down to one msvc version recently, instead of 2 or 3, as each is 3.5gb install size as also includes windows sdk and such.
Forgot to say initially, that you should expect about 4.5 used install-size from running install-components.cmd batch file, where most is msvc(3.5gb roughly) and msys2(900'ish mb reported from windows properties dialog, though read windows has issues calculating such properly because of hardlinks and whatnot, and also seem very excessive to me, so actual size is around 600mb as calculated by 'du -h C:\msys64' linux command, and where additionally an extra hundred could be shaved off to clear cache, which I almost did from install_components.cmd, but decided against in end, as usually is recommended against i.e. not cleaning other older versions fom cache, which of-course is fine, but actually cleaning the single version of each installed package stored there, which is advised against for being able to revert back to working version again if an update F's something up on your system. This is a needed component for gvsbuild anyway, hence I install in that also git, patch and diff and such too, instead of installing/using cygwin or git for windows etc). If wanting save the around 100mb for cache, and it shouldn't honestly hurt in our case here regardless, as not updating msys2 after initial install/update, atleast not from my scripts(and is just tools used during, and not going to be included in the build deluge or components), then you can run this from a command-prompt, or win+r dialog, and not need admin rights for this:
Code: Select all
C:\msys64\usr\bin\pacman.exe -Scc --noconfirm
That line could also be added to install_components.cmd if wanted, somewhere after the msys2 install and update part, for future use).
If you want, you can add new line with:
Code: Select all
As last line to all scripts, so they don't close when finished, and so you can see if error'ed out or not, and which I always do during testing, but not afterwards as I e.g sometimes start scripts from my Linux system, where I have setup a system where I run a command with the scripts I want run after each other and then the win10 VM is started headless in background and batch-files are run in there and close VM afterwards, but that would not work if using such pause command as each script would block the next script from running as would need a key press to continue to next script and not be automatic anymore.
You can make own scripts for different scenarios, where you make new text file ending in bat or cmd, and add on each line "call pathToScriptToRun" and repeat new lines of that underneath, with each new script you want run after eachother, and then rightclick/run-as-admin for that new script, just like you would do with the others, so e.g one script which build all, another which build only this and that, etc, but there's too many combinations for doing that for all scenarios, so I didn't include that in archive, as couldn't decide either which scenarios to include and which not to.