BMK/maxutil.mod do not respect other BlitzMax installations

[GWRon]

For now BMK puts stuff into environment variables. Not that bad. The bad thing is, that BMK prefers the environment variable over the application dir of the executable.

So if you compile with another BlitzMax installation (eg a "stable one" or with "legacy blitzmax") then they will put their paths into the environment variable your current BlitzMax session will then read.

This results in "installation #2" trying to find MinGW of "installation #1". Same for all other processes based on the path BlitzMaxPath() returns.

Means if you eg. used "legacy" next to your "NG" and compile something with "legacy" first it will set its own path as "BMXPATH". Now you want to compile something with "NG" and it finds this "BMXPATH" environment variable pointing to the "legacy" directory. There it tries to find "MinGW" ... and might fail (or even worse: find a MinGW there which is outdated and leads to a mix of "new-gcc-compiled modules" and "old-gcc-compiled project code").

In my opinion the BMX-path should be first of all tried to get found "locally" and if the "bin" folder was not to find then fall back to such an environment path.

[GWRon]

Something like this:

Function BlitzMaxPath$()
	Global bmxpath$
	If bmxpath Return bmxpath
	
	Local p:String
	'first try local dir
	p=AppDir
	Repeat
		Local t$=p+"/bin/bmk"
		?Win32
		t:+".exe"
		?
		If FileType(t)=FILETYPE_FILE
			putenv_ "BMXPATH="+p
			bmxpath=p
			Return p
		EndIf
		Local q$=ExtractDir( p )
		If q=p Exit
		p=q
	Forever
	'try environment dir
	p=getenv_("BMXPATH")
	If p
		bmxpath=p
		Return p
	EndIf
	Throw "Unable to locate BlitzMax path"
End Function

Could do. What disadvantages do you see in having a "local dir first" approach?

[GWRon]

Another question: is all this environment-variable thing still needed in the NG-toolchain? Maybe it was only needed for the fasm/ld/... approach of legacy?

[GWRon]

There is another location potentially creating issues:

bmk_config.bmx:

?Win32
'Fudge PATH so exec sees our MinGW first!
Local mingw$=getenv_( "MINGW" )
If mingw
	Local path$=getenv_( "PATH" )
	If path
		path=mingw+"\bin;"+path
		putenv_ "PATH="+path
	EndIf
EndIf

So once you execute BMK-NG and the environment variable "MINGW" was set then BMK will prepend this variable to the PATH environment variable.
What happens if you execute it again? Is it added again and again?
Shouldn't it restore the path once BMK is finished executing it's commands?

[GWRon]

If there are requirements to override "mingw path" via environment variables then you should make sure to remove the environment variable after usage

I would prefer to use one of the ".bmk" files (config.bmk or custom.bmk) for this purpose. That way you could simply have a customized .bmk file for this particular instance (so each BlitzMax-Install-Dir has its adjusted config file if required).
What is the benefit?

For now each BlitzMax(NG) installation with updated BMK would either use
thisInstall/MinGW32(x86,x64)/bin
or
%MINGW%/bin

Now assume you have MinGW installed for your C programming - it set the MINGW path of your likes.
Now you install legacy BlitzMax (with updated BMK) and so you need to store a BlitzMaxLegacy/MinGW32 (if it differs to the C-MinGW one).
Then you install BlitzMaxNG and might get the very same MinGW32 but you need to store it separately as the "%MINGW%" is used by the MinGW you installed for your C programming.

Having a path option in your custom.bmk or config.bmk means we could point to a custom directory in both installations: your legacy and your NG one.

So at the end you have this priority:

• custom.bmk / config.bmk sets a bmk variable (not an environment one!)
• bmk checks variable<>"" and if it is a valid directory
• if it fails it falls back to "MinGW32 / x86 / x64"
• if that fails it falls back to "environmental variable" ("MINGW")
• if that fails it falls back to "local blitzmax lib/bin dir"

So in essence we just prepend the option to define a custom directory in one of the .bmk files BMK opens right on start.

edit: if you think this is "too much" and "not needed": is there any need to use "%MinGW%" with the NG variant of BMK? If the local BlitzMax/MinGW is the only one we should ever use, than there is no need to check the "%MINGW%" environmental variable.

[Kerntrick]

I have my NG mingw in my path but my %mingw% path is set to another version (compatible w/ monkey ). I've not encountered a problem so far. What sort of errors would come up?

[GWRon]

As described above it should not create trouble if you only use one single BlitzMax installation (or something else utilizing "%BMXPATH%".

The trouble starts if you have multiple installations and run them in the same session as the first run will set "BMXPATH" to its own path. The second run (of the same or another installation) will find this "BMXPATH" and use this - instead of a locally available MinGW.
This leads to "install2" using "install1/MinGW" rather than "install2/MinGW".

[woollybah]

I find it hard to believe that an application calling putenv() will affect anything other than its own environment.
For example :

SuperStrict

Framework brl.standardio

Local mingw:String = "C:\hello_world"

Local path$=getenv_( "PATH" )

Print "BEFORE : " + path

If path
	path=mingw+"\bin;"+path
	putenv_ "PATH="+path

	Print "AFTER  : " + path
EndIf

If you run this on the command line, and then echo %PATH% afterwards, the path should be the same as it was before running it.

From what you are saying, this is not the case?

[GWRon]

Will have to test it - at least I had issues in one of my VMs when building Windows stuff.

Even if it works only "for this process" then the issue of existing "MINGW"-variables is there: if something (like a legacy BlitzMax installation) created a global "MINGW" environment variable, then maxutil.mod will prefer this over a locally available MinGW.

[GWRon]

Seems you are right about the "local scope" of the environment changes. So it must be a different reason for the NG thing having picked up the legacy's MinGW that time.

Regardless of this - and as written some posts earlier:

There is another location potentially creating issues:

bmk_config.bmx:

?Win32
'Fudge PATH so exec sees our MinGW first!
Local mingw$=getenv_( "MINGW" )
If mingw
	Local path$=getenv_( "PATH" )
	If path
		path=mingw+"\bin;"+path
		putenv_ "PATH="+path
	EndIf
EndIf

While putenv_ only changes stuff for this very process doesn't getenv_ read from what was set before the process started?

https://blitzmax.org/docs/en/setup/win32/ :

Using your own MinGW
Legacy versions of BlitzMax for Win32 required you to install MinGW separately and then set up environment variables in order for BlitzMax to be able to rebuild its modules or use third-party libraries.

So if you once installed legacy and configured a "MINGW" environment variable pointing to "C:\oldMinGW", wouldn't this then be used by NG then?