BMax NG Current Stable Version?

Started by _PJ_, August 17, 2019, 20:27:22

Previous topic - Next topic

_PJ_

I have been working to install the "NG" version of BMax environment.

My intention is to be able to complie and deploy to Windows AMD64 target

When I open the "About" box of the "MaxIDE" lightweight, I am presented with the following:

MaxIDE 1.52 [ng] (x64)
BCC Version: bcc[ng] Relesase version 0.105
BMK Version: bmk 3.35 mt win32-x64 / gcc 080100 (cpu x64)
BlitzMax Path: %ProgramFiles%\BlitzMax
MinGW Path: unavailable

FASM Version: 1.69.14
GCC version: n/a
G++ Version: n/a

I'm a little concerned about the "Unavailable" and "n/a" records and would also like to know if I have everything up-to-date (excluding unstable, beta and/or tentative test builds) and if not, how should I go about obtaining the required.

Thanks for your help. Any advice/recommendation welcome. I'm very unsure as to what I'm doing with this whole MinGW/building/TDC or whatever stuff. I have no desire to deploy to non-Windows environs.




dawlane

I'm not on my Windows machine at the moment, but open a command prompt and change directory in the MinGW's bin directory within the BlitzMax NG directory (the name of the MinGW directory depends on which of the three downloads you chose. Once you are in the MinGW bin directory, issue the command g++ --version to get the version information for that compiler. I think that the latest stable downloads use GCC MinGW 8.1.0/7.3.0 with posix threading and either dwarf (32 bit output) or seh (64 bit output) exception handling.

Henri

Hi PJ,

I believe that MaxIDE requires MinGW environment variable to be set, so that it can find your MinGW installation.

For NG this is only cosmetic, as bmk looks MinGW internally from <bmx-ng-folder>\<mingw-folder> .

If you are only deploying for 64-bit, then there should be <mingw-folder> named MinGW32x64. This holds the 64-bit MinGW.

-Henri
- Got 01100011 problems, but the bit ain't 00000001

Derron

MaxIDE shows what "brl.mod/maxutil.mod/maxutil.bmx" returns within "MinGWPath:string()". So when you compile MaxIDE it includes that function there.


For me it looks this way:
Code (BlitzMax) Select


Function MinGWPath:String()
?Not win32
Return ""
?win32
If Not _minGWPath Then
Local path:String
' look for local MinGW32 dir
' some distros (eg. MinGW-w64) only support a single target architecture - x86 or x64
' to compile for both, requires two separate MinGW installations. Check against
' CPU target based dir first, before working through the fallbacks.

Local cpuMinGW:String

?win32x86
cpuMinGW  ="/MinGW32x86"
?win32x64
cpuMinGW = "/MinGW32x64"
?win32
path = BlitzMaxPath() + cpuMinGW + "/bin"
If FileType(path) = FILETYPE_DIR Then
' bin dir exists, go with that
_minGWPath = BlitzMaxPath() + cpuMinGW
Return _minGWPath
End If

path = BlitzMaxPath() + "/MinGW32/bin"
If FileType(path) = FILETYPE_DIR Then
' bin dir exists, go with that
_minGWPath = BlitzMaxPath() + "/MinGW32"
Return _minGWPath
End If

' try MINGW environment variable
path = getenv_("MINGW")
If path And FileType(path) = FILETYPE_DIR Then
' check for bin dir
If FileType(path + "/bin") = FILETYPE_DIR Then
' go with that
_minGWPath = path
Return _minGWPath
End If
End If

' none of the above? fallback to BlitzMax dir (for bin and lib)
_minGWPath = BlitzMaxPath()
End If

Return _minGWPath
?
End Function


Checking "blame" for this file:
https://github.com/bmx-ng/brl.mod/blame/master/maxutil.mod/maxutil.bmx
Shows that this function was added "3 months ago".

Checking the maxide.bmx source now:
https://github.com/bmx-ng/maxide/blame/master/maxide.bmx
it shows that the MinGWPath() call was added at May 8th by Brucey.
(commit was: https://github.com/bmx-ng/maxide/commit/91b59dbcb3fcee3e6f70d20f5695d59099761a58)

Looking there you see that the OLD MinGW check tried to find "yourBlitzMaxFolder\MinGW32" first and then falling back to the environment variable defined directory.


----

To have it working you need a MaxIDE built with newer maxide sources and newer brl.mod sources. v0.105 was released on may 5th ...so before the above fixes/adjustments.



TLDR: with the next release this will be displayed correctly.


bye
Ron

_PJ_

Thanks very much for the informative (and very swift) replies!

Quoteissue the command g++ --version to get the version information for that compiler.
Within BlitzMax directory, The folder "MinGW32x64" exists with all its contents.
The feedback from the g++ --version command mentioned "x86_64_posix-reh" and "8.1.0" so all seems good for this at least.

QuoteI believe that MaxIDE requires MinGW environment variable to be set, so that it can find your MinGW installation. For NG this is only cosmetic, as bmk looks MinGW internally from <bmx-ng-folder>\<mingw-folder> .
Okay this is good to know, it explains a lot.
It's worth noting the MinGW32x86 folder is empty and this would make sense as I'm only wanting 64-bit outputs - this would also explain why I get gcc compiler not found errors if I try compiling for x86 - I've not set any envvars.


Quote
To have it working you need a MaxIDE built with newer maxide sources and newer brl.mod sources. v0.105 was released on may 5th ...so before the above fixes/adjustments.
Thank you, Derron. Way more detail than I wanted but I'm extremely appreciative and it explains the "unavailable" nitce very clearly. Now I know that I don't really need to worry about it :).

Just for a final point to note if/when I do want to work with a later version of NG, I would download the source and run BMK or open with the current IDE and compile from there?????






Hezkore

#5
To update you'll want to grab and update all the modules first.
Then compile BMK and BCC with your current BMK, yes.
You'll find all of that over at: https://github.com/bmx-ng

I've got a little Crontab bash script setup on my server that creates an update for me at midnight.
It only contains the modules, along with a compiled BCC and BMK for both Windows and Linux (x64 only).
I've kept it private for some time, but I guess you can use it as well.

You can find it over at: http://hezkore.com/blitzmaxng/
I've done some cleaning so you'll only find one update for now.
But as I said; you'll want to apply this on top of your BlitzMax NG install, as this is only the modules and build tools.

So steps from a clean install would be:
Grab BlitzMax NG from blitzmax.org.
Download update from http://hezkore.com/blitzmaxng/.
Extract the update into your BlitzMax NG folder and overwrite any files.
Done.
Simplicity is the ultimate sophistication. 🚀
GitHub
BlitzMax for VSCode
BlitzMax for Vim

Dabz

Quote
So steps from a clean install would be:
Grab BlitzMax NG from blitzmax.org.
Download update from http://hezkore.com/blitzmaxng/.
Extract the update into your BlitzMax NG folder and overwrite any files.
Done.

Thats a pretty cool solution that Hezkore! *tips hat*

Dabz
Intel Core i5 6400 2.7GHz, NVIDIA GeForce GTX 1070 (8GB), 16Gig DDR4 RAM, 256GB SSD, 1TB HDD, Windows 10 64bit

Derron

@hezkore
Thanks for "sharing".

Remember to update the .bmk files too (at least the ones you need to provide next to bcc/bmk: core.bmk, make.bmk and optional custom.bmk). Especially make.bmk sometimes receives updates (to fix icons etc).


bye
Ron

Hezkore

Quote from: Derron on August 19, 2019, 09:30:33
Remember to update the .bmk files too (at least the ones you need to provide next to bcc/bmk: core.bmk, make.bmk and optional custom.bmk). Especially make.bmk sometimes receives updates (to fix icons etc).

Yeah that's true.
I normally throw those into 'bin' myself, but I guess I could just automatically place them in 'bin'.
(never planned on this being public)
I'll change that once I get home later today.
Simplicity is the ultimate sophistication. 🚀
GitHub
BlitzMax for VSCode
BlitzMax for Vim

Hezkore

Alright! 'core.bmk' 'make.bmk' and 'custom.bmk' will now come with the update.
Simplicity is the ultimate sophistication. 🚀
GitHub
BlitzMax for VSCode
BlitzMax for Vim

Derron

Not sure about custom.bmk - as this might be individualized already (it contains setup for android development etc.).
(for such things it might be handy to have BMK/BCC use a custom.default.bmk and a custom.bmk which overrides default provided values).



bye
Ron

Hezkore

I included what comes when you download BlitzMaxNG from blitzmax.org.
Simplicity is the ultimate sophistication. 🚀
GitHub
BlitzMax for VSCode
BlitzMax for Vim

Derron

#12
For most situations this will be fine I think.
Just remember that yours is an "update" while the release is a "full installation".

Regardless of such little annoyancies (take care of changed files) this 7z-packages might be helpful for some here looking for updated/bleeding edge NG builds.


Edit: One thing people should consider with your archives: if you just override existing files you keep the precompiled modules (done with older bmk,bcc - and older module sources).

bye
Ron

Hezkore

Quote from: Derron on August 19, 2019, 17:51:08
Edit: One thing people should consider with your archives: if you just override existing files you keep the precompiled modules (done with older bmk,bcc - and older module sources).

Wouldn't the timestamp be different for the new modules, which triggers a rebuild for anything that's changed?
Or are you talking about modules that hasn't changed and has been compiled with an older BMK mixing with newer modules?
So far I haven't had any problems with my updates, and I've used them since March.
But yeah, ideally you'd have some sort of "updater" take care of all of this.
Simplicity is the ultimate sophistication. 🚀
GitHub
BlitzMax for VSCode
BlitzMax for Vim

Derron

Both cases could happen:

"not changed" modules compiled with an eg. "broken BCC" might not get their required recompiles.
Or if you did not compile all modules but just the one you were using in your project and are switching to another project after updating, this will only compile the non-yet-compiled modules it used there. If stuff now changed here and there ... you will see a lot of errors spit out.

"timestamp" is not guaranteed to be working across platforms. Depending on where you store stuff and how you synchronize timestamps can become borked (eg. "ext3 - samba share to ntfs" - just seen that in "FreeFileSync" which lists 1000 files changed while I only changed 5 files on my working laptop today).
More important here is: assume somebody just compiled his (old) modules AFTER you updated yours ("oh there is an update, will just install it now"). So we have "original source" -> "your source" -> "compiled module" timestamps. BMK checks dates and sees that there is something compiled and newer than the sources and thinks "no need to compile".


So yes, an "updater" or "cleaner" or "maintenance" thing is the better approach.


bye
Ron