Simplify release process

[hiran]

I implemented an almost complete version bump in
PR 430.

Next step may be to figure out how to include the still missing libreoffice documents.

[hiran]

cmd.exe has issues with relative paths. Have you tried the same test under PowerShell?

This did not give me any different results as described above.

Code: Select all

PS C:\Users\User> C:\oolite\oolite.app\oolite.exe

Yet I verified: Undoing the patch and running 'correctly' brought up Oolite v1.90.

[Commander_X]

Confirmed from me as well. Can't believe that this has gone unnoticed for more than ten years!

I think I have a fix though. Can you please test this executable? https://we.tl/t-X3SFuWdypr
It works perfectly under Powershell and almost perfectly under cmd.exe for me. By perfectly I mean that it works from any folder and with both absolute and relative paths. On cmd.exe it seems that relative paths still have an issue, but given that Powershell works, I would dare suggest a potential problem with cmd's path handling.

Anyway, if you can let me know how this one goes for you, we should hopefully be able to commit the fix soon.

Both in Wine (and its cmd.exe) and my Windows 10 instance (both cmd.exe and PowerShell) it doesn't start. It logs, though, with the last line in the log:

Code: Select all

[descriptions.verify]: ***** FATAL: Tried to verify descriptions, but descriptions was nil - unable to load any descriptions.plist file.

EDIT: It also creates GNUstep and Logs folders in the current directory. It seems the call

Code: Select all

GetCurrentDirectory(MAX_PATH_LEN - 1, currentWorkingDir);

in SDL/main.m to prepare the GNUSTEP_* environment variables is the culprit. It should be replaced with retrieving the folder where the exe file resides.

[another_commander]

EDIT: It also creates GNUstep and Logs folders in the current directory.

Hmm, this is the behaviour before the attempted fix. Are you sure you are using the file I posted?

It seems the call

Code: Select all

GetCurrentDirectory(MAX_PATH_LEN - 1, currentWorkingDir);

in SDL/main.m to prepare the GNUSTEP_* environment variables is the culprit. It should be replaced with retrieving the folder where the exe file resides.

Correct and this is what the posted exe was trying to do. It seems though that I indeed messed up something somewhere, because when I run my posted exe on my Win10 work computer, it failed to start as well. I think I may have posted an executable without the final fix embedded, so let's try this one more time, if that's OK with you. Here is an executable that works for me: https://we.tl/t-GQIWWUGoT1

And just to be on the safe side, here is the source code diff showing what this exe is exactly supposed to do. It does 3 things: 1. Gets the directory oolite.exe is being run from, 2. sets this directory as the very first element of the PATH environment variable and 3. changes internally to that folder to ensure that GNUstep can see the expected and correct file/folder structure. Here is the patch if you want to build it yourself:

Code: Select all

diff --git a/GNUmakefile b/GNUmakefile
index e41d1c32..42316f54 100755
--- a/GNUmakefile
+++ b/GNUmakefile
@@ -31,9 +31,9 @@ ifeq ($(GNUSTEP_HOST_OS),mingw32)
 
     ADDITIONAL_INCLUDE_DIRS      = -I$(WIN_DEPS_DIR)/include -I$(JS_INC_DIR) -Isrc/SDL -Isrc/Core -Isrc/BSDCompat -Isrc/Core/Scripting -Isrc/Core/Materials -Isrc/Core/Entities -Isrc/Core/OXPVerifier -Isrc/Core/Debug -Isrc/Core/Tables -Isrc/Core/MiniZip
     ADDITIONAL_OBJC_LIBS         = -L$(WIN_DEPS_DIR)/lib -lglu32 -lopengl32 -lopenal32.dll -lpng14.dll -lmingw32 -lSDLmain -lSDL -lvorbisfile.dll -lvorbis.dll -lz -lgnustep-base -l$(JS_IMPORT_LIBRARY) -lwinmm -mwindows
-    ADDITIONAL_CFLAGS            = -DWIN32 -DNEED_STRLCPY `sdl-config --cflags` -mtune=generic -DWINVER=0x0601
+    ADDITIONAL_CFLAGS            = -DWIN32 -DNEED_STRLCPY `sdl-config --cflags` -mtune=generic -DWINVER=0x0601 -D_WIN32_WINNT=0x0601
 # note the vpath stuff above isn't working for me, so adding src/SDL and src/Core explicitly
-    ADDITIONAL_OBJCFLAGS         = -DLOADSAVEGUI -DWIN32 -DXP_WIN -Wno-import -std=gnu99 `sdl-config --cflags` -mtune=generic -DWINVER=0x0601
+    ADDITIONAL_OBJCFLAGS         = -DLOADSAVEGUI -DWIN32 -DXP_WIN -Wno-import -std=gnu99 `sdl-config --cflags` -mtune=generic -DWINVER=0x0601 -D_WIN32_WINNT=0x0601
     ifneq ($(HOST_ARCH),x86_64)
         ADDITIONAL_LDFLAGS       += -Wl,--large-address-aware
 #     else
diff --git a/src/SDL/main.m b/src/SDL/main.m
index ca066a52..3b8f53e0 100644
--- a/src/SDL/main.m
+++ b/src/SDL/main.m
@@ -65,7 +65,18 @@ int main(int argc, char *argv[])
 	#define MAX_PATH_LEN 256
 	char currentWorkingDir[MAX_PATH_LEN];
 	char envVarString[2 * MAX_PATH_LEN];
-	GetCurrentDirectory(MAX_PATH_LEN - 1, currentWorkingDir);
+	DWORD bufferSize = MAX_PATH_LEN;
+	QueryFullProcessImageName(GetCurrentProcess(), 0, currentWorkingDir, &bufferSize);
+	char *probeString = strrchr(currentWorkingDir, '\\');
+	if (probeString)  *probeString = '\0';
+	
+	// Prepend the system's PATH env vraiable with our own executable's path
+	// this way we can once again launch from the command line and batch files like we used to
+	char finalPath[16 * MAX_PATH_LEN];
+	char *systemPath = SDL_getenv("PATH");
+	strcpy(finalPath, currentWorkingDir);
+	strcat(finalPath, ";");
+	strcat(finalPath, systemPath);
 
 	#define SETENVVAR(var, value) do {\
 			sprintf(envVarString, "%s=%s", (var), (value));\
@@ -73,11 +84,14 @@ int main(int argc, char *argv[])
 			} while (0);
 	
 	SETENVVAR("GNUSTEP_PATH_HANDLING", "windows");
+	SETENVVAR("PATH", finalPath);
 	SETENVVAR("GNUSTEP_SYSTEM_ROOT", currentWorkingDir);
 	SETENVVAR("GNUSTEP_LOCAL_ROOT", currentWorkingDir);
 	SETENVVAR("GNUSTEP_NETWORK_ROOT", currentWorkingDir);
 	SETENVVAR("GNUSTEP_USERS_ROOT", currentWorkingDir);
 	SETENVVAR("HOMEPATH", currentWorkingDir);
+	
+	SetCurrentDirectory(currentWorkingDir);
 
 	/*	Windows amibtiously starts apps with the C library locale set to the
 		system locale rather than the "C" locale as per spec. Fixing here so

Hope it works this time.

[Commander_X]

[...] Here is an executable that works for me: https://we.tl/t-GQIWWUGoT1
[...]
Hope it works this time.

Yup, this one works, great job!

[hiran]

Confirmed from me as well. Can't believe that this has gone unnoticed for more than ten years!

I do not think it was unnoticed. Not completely. At least on Linux it was resolved by adding a workaround to the wrapper script.

[...] Here is an executable that works for me: https://we.tl/t-GQIWWUGoT1
[...]
Hope it works this time.

Yup, this one works, great job!

I can now partly confirm it works. I still only have a VM with Windows to test, and OpenGL 3 is not yet fixed.
But with the currently latest download (Oolite development version 1.91.0.7443-230629-a794bc2 (x86-64 test release) under Windows 10.0.22621.1848 64-bit) I see the same behaviour regardless which of the two commands I use:

Code: Select all

C:\Oolite\oolite.app>oolite.exe
C:\Users\User>\Oolite\oolite.app\oolite.exe

[hiran]

No further simplification will happen. See https://bb.oolite.space/viewtopic.php?p=289876#p289876