Nice
Yeah, msys2 username/dir can be changed, independant of windows, but seemingly is not needed, and was a python parsing issue here, as msys2 did work it seems.
The error'ed move commands, after thinking about it, must be because during the error'ed out initial run, then the data folder under overlay was deleted, but no new copied into place, as the gvsbuild failed. Then at subsequent run, then those files are missing and so cannot be moved over. The missing files will be needed for subsequent runs, as else will always be missing, so if you could copy them into place from e.g. your deluge local install, as also would make deluges fail to run when building those later, because of said missing files/folders. The missing files/folder can be found in data folder in e.g. 'C:\Program Files\Deluge', or whereever having installed into. Maybe/likely I should have added another folder under deluge2, to store these things and copy over from there, each time from gvsbuild.cmd, instead of as now, as if a build fails, like now, then would miss those files, but just thought was no need, since always available from last gvsbuild build under overlay anyway, and didn't think about the issue of a failed build possibly.
Sorry for inconvenience.
About libtorrents, yes they will show lots of warnings of deprecated commands and whatnot of this and that, which is irrelevant and if the slightest real error happens then the build fails, which I messed with I believe not exaggerating 50 times minimum initially when getting these libs to even finish build without error'ing out. It's the build-files that's provided that gives these warnings and not my scripts. One of the warnings is for strictly if using msvc 2017 then will fail when not providing msvc version specifically, but the default value of just msvc, which means default installed msvc version, will work fine for msvc 2019. I initially copied the vcvars file in place to shut it up, but after retesting some things months ago, then I just removed that part, as was just for appearance and didn't change end-result/functionality, but up to you of-course. It looks like it fails, but actually that is a message of it working, oddly, if you added a pause command as last line, to be able to see it. I just check filedate under libtorrent.pyd under the libtorrent folder of lt1.1 or lt1.2 dir(under Lib\site-packages) to make sure - if the output, if adding that pause - states this here, then it's working:
Code: Select all
common.copy libtorrent.lib
bin\msvc\rls\adrs-mdl-64\bst-lnk-sttc\crypt-opnsl\lbtrn-lnk-sttc\optmz-spc\thrd-mlt\libtorrent.lib
1 file(s) copied.
common.copy libtorrent.pyd
bin\msvc\rls\adrs-mdl-64\bst-lnk-sttc\crypt-opnsl\lbtrn-lnk-sttc\optmz-spc\thrd-mlt\libtorrent.pyd
1 file(s) copied.
...updated 272 targets...
running build
running build_py
package init file 'libtorrent\__init__.py' not found (or not a regular file)
package init file 'libtorrent\__init__.py' not found (or not a regular file)
1 file(s) copied.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
The system cannot find the file specified.
You can try remove the double rd lines if wanted, for avoiding all these "cannot find file", but I would'nt recommend it, as will hit you maybe once in 10-20 runs, with that annoying async file-delete timing issue error of windows, several threads about on stackexchange etc, and hit me plenty of times personally, at random times, untill reading different workarounds where this the simplest, as never happens twice in row apparantly. Also, I could just use 'rm -rf' from msys2 instead, which I guess would work, but unsure if an underlying windows issue, which it seems as is described as exisitng both in rd, a powershell delete applet and dotnet delete function, so internal windows delete timing issue when run from script.
Yes, that is on purposse that these lines are omitted. They are used in lt1.2 because they additionally are copied into deluge folders as are default deluge libtorrent version when not changing away from default libtorrent 1.2.x in installer. As you haven't built deluges yet, I guess, then no worries, as gets inherrented from overlay when later building those, hence my mention of order of scripts not matter previously.
No, I honestly never looked into that optimization option, and what even stands for, but sure do if you deem appropriate
Good job again, changing things to your liking. I agree it would be faster to keep things around, especially when static versions used all the time, and was just a habbit of mine to clean up after myself and have tidy build-dirs left afterwards etc.
Edit: The extra additional rd lines, can obviously just be shut up by echhoing stderr/out or whatever named on windows to NUL, to get cleaner output, though personally didn't trouble me much, as said did run usually without even being able to see the output often, when not testing it of-course, and just had a command run that checks filedate or runstate afterwards.