MegaGlest Forum
MegaGlest => Bug reports => Closed bug reports => Topic started by: Omega on 19 July 2014, 14:49:47
-
It appears that the script located in mk/windoze/CopyWindowsRuntimeDlls_2010.bat (which the readme describes as necessary for running the program) is outdated.
First of all, either the readme is missing crucial information about how to run this script or all the paths are wrong. It should be copying files to the data/glest_game directory, but instead copies to the current directory. Strangely enough, there's commented out lines (for obviously outdated DLLs) that have the right path. It's the active lines that have the wrong paths.
Anyway, even after manually copying over all the files, the program doesn't run. It appears that not all libraries are included. I think it was just the 7zip stuff that was missing (although I actually copied all the DLLs and the plugins and lua folder from my install of 3.9.0).
As an aside, I also have two related observations:
- The error messages when the program was started with missing libraries is very bad. It basically says "MegaGlest encountered an error and must close, send us this dmp that you can't read" instead of a more ideal notification about the exact libraries that are missing. It seems that *some* libraries do have better error messages (I initially forgot to copy DLLs and received an error about missing libvlc).
- In mk/windoze/CopyWindowsRuntimeDlls_2010.bat, there's some copy operations that are only performed if a file does not already exist. IMO, this is not an ideal approach. What if the libraries need to be updated in the future? Not overwriting the files would fail to update them properly.
- The commented out lines (that start with rem) should probably be removed. They hold no current value and made me originally question if these files were supposed to be copied too (ie, they're confusing to the reader). All those files aren't used anymore, and most don't even exist in the windows deps package.
This is relevant as per the develop branch at rev 31def0dc1a.
-
It appears that the script located in mk/windoze/CopyWindowsRuntimeDlls_2010.bat (which the readme describes as necessary for running the program) is outdated.
First of all, either the readme is missing crucial information about how to run this script or all the paths are wrong. It should be copying files to the data/glest_game directory, but instead copies to the current directory.
... folder from my install of 3.9.0
Since ~3.9.3-dev (develop branch) script works slightly differently and data/glest_game directory should be absolutely clean from the "trashes" if you need something for 3.9.0 (why?) then you should look for old commit, tagged 3.9.0.
2. ...In mk/windoze/CopyWindowsRuntimeDlls_2010.bat, there's some copy operations that are only performed if a file does not already exist. IMO, this is not an ideal approach. What if the libraries need to be updated in the future? Not overwriting the files would fail to update them properly....
Process of overwriting files doesn't goes hand in hand with stability.
Wiki says: (https://docs.megaglest.org/MG/Windows_Compiling)
... is usually due to outdated build dependencies. Check http://sourceforge.net/projects/megaglest/files/ for windows_deps.7z when it was last updated, and if it's more recent than the one you have in source\ (or if you are unsure), then recursively delete both source\windows_deps\ and source\windows_deps.7z. ...
and then launch script.
-
if you need something for 3.9.0 (why?) then you should look for old commit, tagged 3.9.0.
I'm working on the development copy. The only reason I mentioned 3.9.0 is because that's the only place I could get the 7-zip files from (they're not in the windows deps).
Process of overwriting files doesn't goes hand in hand with stability.
But overwriting is exactly what patching does.
Wiki says: (https://docs.megaglest.org/MG/Windows_Compiling)
... is usually due to outdated build dependencies. Check http://sourceforge.net/projects/megaglest/files/ for windows_deps.7z when it was last updated, and if it's more recent than the one you have in source\ (or if you are unsure), then recursively delete both source\windows_deps\ and source\windows_deps.7z. ...
and then launch script.
But both the script and deps archive seem to be outdated. And I'm running develop/HEAD. At any rate, this was a fresh install. source/windows_deps did not previously exist. I just downloaded the windows deps archive last night.