-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BMK/maxutil.mod do not respect other BlitzMax installations #86
Comments
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? |
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? |
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. |
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). For now each BlitzMax(NG) installation with updated BMK would either use Now assume you have MinGW installed for your C programming - it set the MINGW path of your likes. 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:
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. |
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? |
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. |
I find it hard to believe that an application calling putenv() will affect anything other than its own environment.
If you run this on the command line, and then From what you are saying, this is not the case? |
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. |
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:
While https://blitzmax.org/docs/en/setup/win32/ :
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? |
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.
The text was updated successfully, but these errors were encountered: