Splitting BRL.System

BlitzMax Forums/BlitzMax Programming/Splitting BRL.System

Brucey

(Posted 2014) [#1]

Hallo :o)

I'm thinking of splitting BRL.System module into two parts, to work based on the "Factory" design that other modules are already using.

All the current Driver functionality would be pulled out into a new module, and the remaining BRL.System would simply be a stub to drive whichever "system" module you had loaded.

At the moment, BRL.System makes lots of assumptions - like that you *really* want to use X Windows on Linux. You can't create proper console applications on Linux if you use BRL.System, because of dependencies it pushes onto your application.

Also, the current BRL.System makes integrating such things as an SDL backend much more complex than it needs to be. SDL comes with its own display, keyboard and mouse handling functionality that is already implemented by BRL.System in its own way.

Thoughts, comments and suggestions welcome :-)

GfK	(Posted 2014) [#2]

More flexibility is always good.

Who was John Galt?

(Posted 2014) [#3]

Sounds like a solid plan.

BlitzSupport

(Posted 2014) [#4]

I seem to recall I had to hack the system date command (forget the name off-hand) out of BRL.System to get it to work on a remote Linux server -- other stuff in the module caused a segfault, so I copied-and-pasted the one command into my own program!

So, yeah, sounds like a good idea.

Brucey

(Posted 2014) [#5]

Okay, so that seemed painless enough...

An example can be seen here :

https://github.com/bmx-ng/brl.mod/tree/master/system.mod
https://github.com/bmx-ng/brl.mod/tree/master/systemdefault.mod

BRL.SystemDefault contains all the functionality of the old BRL.System.
BRL.System is just a stub declaring a system driver base class, and the standard system functions.

Now I can do things like this, and not worry about BlitzMax getting in the way:

Type TSDLSystemDriver Extends TSystemDriver

	Method New()
		SDL_Init(SDL_INIT_VIDEO)
	End Method

	Method Poll()
		bmx_SDL_Poll()
	End Method
 ...
 ...
 ...
End Type

Driver = New TSDLSystemDriver

Yay! ;-)

Henri

(Posted 2014) [#6]

Seems reasonable enough.

-Henri

Derron

(Posted 2014) [#7]

Brucey's real name is Bruce A Frankenstein - and he keeps things alive.

Deep below is castle in feral Scotland he experiments with dead and left behind bodies of code. Now try to envision his diabolic laugh when "it" suddenly is alive.

*shivering*

PS: Like said per mail I hope you find a way to cut down binary size to reasonable amounts when using SDL (without sdl graphics, sound, networking ...). The static libs are not that small (windows lib is >5mb). Of course for "games" a binary can get bigger, but for small tools (eg. without X11-requirement on linux) size indeed does matter.

graphics example: sdl (stripped) 1.5mb
graphics example: brl (stripped) 274kb

sdl:
Framework sdl.sdlgraphics
brl:
Framework brl.systemdefault
Import brl.glgraphics

I know that it is bigger, because the lib contains more things - but maybe things can get "split" into multiple parts. I also know: get things working first, optimization can be done later - but maybe such things have to get tinkered out before (conception wise).

bye
Ron

Brucey

(Posted 2014) [#8]

@Size
I don't see a use for anyone using SDL without its graphics stuff, so I've built it accordingly.

The reason I want a System module without all that extra stuff that BRL.System has, is so that I can create command-line tools and such without lots dependencies that it doesn't need. With the current BRL.System you cannot create proper, small command-line tools because it is doing all kinds of things like event handling - things that such tools would never require.

Now it's split, I can rework my curses module to have a proper system driver that doesn't have those external dependencies... for example.

Derron

(Posted 2014) [#9]

So it is 5 MB for "graphics" (Windows) or does that include image loader functionality already?

@BRL.system
Somehow I had "SDLsystem" in mind .... nvm.

Dunno what happens to the basic file requesters - as soon as you then use something of the SDL-subsystem you will end up with something bigger. If not, no worries and false alarm :p

bye
Ron

ziggy

(Posted 2014) [#10]

Brucey, have you tested SDL with your C++ max translator? Just being curious.

Derron

(Posted 2014) [#11]

Yes.

He mentioned that my frameworks "demoapp" runs - except my GUIInput as KeyChar-Events are not emitted yet. the Demoapp is mentioned in the 64bit-threads already.

bye
Ron

Brucey

(Posted 2014) [#12]

Brucey, have you tested SDL with your C++ max translator?

C max translator :-)
Yes, actually I've only been working on the new compiler with this. Currently tested on x86 for the 3 main platforms.
SDL supports x86, x64, Raspberry Pi, iOS and Android. So it should take care of a lot of potential issues building games for those platforms.

Derron

(Posted 2014) [#13]

That is why I thought of using more modules from SDL (because "they" take care of problems on other targets) ... think audio, input, ... are all subjects of having problems here and there.

bye
Ron

JoshK

(Posted 2014) [#14]

Looking forward to this.

*	(Posted 2014) [#15]

Me too :)

LT	(Posted 2014) [#16]

How will using SDL differ from using OpenGL in BlitzMax? The prospect of making my engine work on all of those platforms is enticing, to say the least!

Brucey

(Posted 2014) [#17]

How will using SDL differ from using OpenGL in BlitzMax?

It won't (or at least, it shouldn't make any difference to your code).
However, it basically replaces the window/context creation, as well as input event handling. On Linux at least, this improves BlitzMax fullscreen functionality on systems with multiple displays.

It also has decent support for controllers (which I've yet to look at implementing), but apparently if your game supports controllers and you were to release it on Steam, the settings for pre-configured controllers in Steam would appear already configured in your game. (so the documentation says. ymmv)

No, I'm not trying to sell Steam, I'm just giving examples of various possible advantages that an SDL backend gives over the default BlitzMax one.

As for other platforms... SDL is known already to work on iOS and Android (and the Pi !). Plugging onto a working backend for those platforms is an order of magnitude less effort than trying to write it oneself.

Anyway, it's all optional, but choice is good, as they say :-)

Derron

(Posted 2014) [#18]

Having a look at what brucey added to "sdl.mod", you will see that other things might come too:

SDL.SDLAudio -> replacement possibility for audio playback. With many games relying on "sdl" you might surely have things installed on linux to get audio playback (open audio).

Check the sdlaudio-example to see streamed ogg playback. Think its time to send brucey your proposals so he could choose his "man" :p.

bye
Ron

LT	(Posted 2014) [#19]

Considering the benefits, I'd be foolish not to try it. Thanks for all of your work on this!

GW	(Posted 2014) [#20]

Slightly ot:
Brucey, I'm a windows user. It seems that so far with bmax-ng, MSWin is going to be a second-class citizen. How can I (and other windows users) help and contribute on the windows side?

Derron

(Posted 2014) [#21]

By charming brucey ... or maybe testing things on Windows and reporting/fixing issues.

seriously: Brucey stated that he wants to make things work first ... which means on OS he uses. Afterwards, the project might receive fixes to make it useable on "other os".

bye
Ron

Brucey

(Posted 2014) [#22]

It seems that so far with bmax-ng, MSWin is going to be a second-class citizen

The DX and (windows) MaxGUI modules for BlitzMax are an order of magnitude more difficult to convert for 64-bit than all the other modules put together. And since it requires a fair understanding of DX/win32 apis to get everything converted properly, it will therefore take longer for those particular modules to be ported.

The other issue is configuring for 64-bit builds with MinGW64 and the bin/lib setup that BlitzMax uses on Windows. I am still not entirely satisfied with my current layout for that (i.e lib for 32-bit and lib64 for 64-bit libs). At least TDM 64 supports building both 32 and 64-bit binaries.

So you see, it's more complicated to get Windows stuff working, whereas for the other platforms you simply tweak here, edit there, and it all *just works*. Even the cross-compile for the Pi on OS X worked first time!

We'll get there. In the meantime you can keep on building 32-bit binaries with BlitzMax proper :-)

LT	(Posted 2014) [#23]

But doesn't SDL allow you to circumvent DX and MaxGUI? If so, I don't see the need for those modules at all. Speaking only for myself, of course. :)

GW	(Posted 2014) [#24]

I understand, Thanks.
btw. I won't be shedding a tear if there is no DX driver. I've used GL exclusively for years and I get the impression that others do to.

Brucey

(Posted 2014) [#25]

But doesn't SDL allow you to circumvent DX and MaxGUI?

It all depends of course what you are doing.
I'd like a working MaxGUI so that I can build a 64-bit native version of MaxIDE for Windows. I already have such for Linux and OS X. And having a 64-bit MaxIDE is fairly good proof of everything working.

And I'd like to be able to say - You can do everything with this that you can do with standard BlitzMax - In which case I need everything working, including DX.

One thing to note, is that bmx_ng-made x86 binaries not as fast as the standard BlitzMax. I generate C and use a generic garbage collector, whereas standard BlitzMax has both a BlitzMax-specific GC, and generates assembler. However, my ARM and 64-bit binaries are somewhat faster than standard BlitzMax's ;-)

LT	(Posted 2014) [#26]

It seems to me that as long as there is some way to do DX, your mission will have been accomplished. But hey, who am I to argue? I'm just happy you're doing it. :)

GW	(Posted 2014) [#27]

Out of curiosity, what are you doing in bMax that you need DX for and you cant do in Opengl?

LT	(Posted 2014) [#28]

I don't see the need for those modules at all.

I'm quoting myself. ;)

I don't personally have a need for DX, but some users insist on it. I assume that's because of better driver support.

Ole JR

(Posted 2014) [#29]

After the splitting of system.mod
glgraphics.mod and timer.mod fail to compile om windows.

Have to change the #include in glgraphics.win32.c and timer.win32.c

#include <brl.mod/system.mod/system.h> need to be #include <brl.mod/systemdefault.mod/system.h>

Another question on BlitzMaxNG (still on windows & maybe the wrong thread to ask):

Shouldn't one be able to (atleast) compile all modules with/without the -h switch?

Running:

bmk makemods -h brl.threads

Give me an exception_access_violation
brl.mod/threads.mod/.bmx/threads.bmx.debug.mt.win32.x86.c: No such file or directory.

Edit:
And then these things are fixed after syncing :-)

Brucey

(Posted 2014) [#30]

Shouldn't one be able to (atleast) compile all modules with/without the -h switch?

One hadn't tried building it in threaded mode yet. Apologies for the minor issues.

Ole JR

(Posted 2014) [#31]

No problem at all!

Now I just have to figure out what goes where from tdm-4.8.1 to the
BlitzMax NG folder for x64 building on windows..

Brucey

(Posted 2014) [#32]

Now I just have to figure out what goes where...

I've a modified script/bat for that, which I can post later. (copies stuff into lib64).
<rant>
However, I'm still not entirely happy with the setup for Windows. The whole "copy stuff from there to here" thing is rather backwards if you ask me. I understand it was designed to be "standalone" because Windows users don't like to install extra stuff, but it would be easier if bmk just looked for everything in MinGW, rather than BlitzMax bin/lib - this way you don't need to copy anything, as it all would stay where it belonged.
On Linux/OS X this is not a problem as you are required to have a dev setup on your box to build stuff.
</rant>
:-p

Maybe now would be a good time to say "for this BlitzMax NG, bmk will look in your MinGW folder for everything it needs" - especially given the fact that you will need MinGW to compile the generated C code anyway.

Unless anyone has any better ideas? :-)

Derron

(Posted 2014) [#33]

IF ... and I say IF ... everything works without having to matter which MinGW-version is installed, we could do this:
- is something in lib64 - use this
- if there is nothing in lib64 - use the minGW available via "%path%" (so globally)

It always is important to make things work (yay!) so if there is something incompatible with MinGW XYZ, you should still have a chance to somehow route it to the MinGW you want to use.

The "lib64" (or lib32) approach is useful as it allows "portable" BlitzMaxNG-packages. No need to install things first, start MaxIDE and you are ready to compile.

I would like to have such things for Linux/Mac too - but things are different there ...

bye
Ron

Ole JR

(Posted 2014) [#34]

I myself doesn't see a problem with using the MinGW path for lib/bin.

Would even say it might take some frustrations away from how it's currently working in BM "classic"..

Like: Want to use an extra mod -> need MinGW -> Installs (some new version of) MinGW, but forget/don't know they need to copy lib/bin to BM folder = fail to compile..

Also way easier to upgrade MinGW that way. Without the need to copy things around..

And as you say. There's no way to get anything done BlitzMax NG without MinGW anyway. Except maybe write code that one can sit and stare at..

Brucey

(Posted 2014) [#35]

No need to install things first, start MaxIDE and you are ready to compile.

Except that you *need* MinGW to use the new bcc. No getting away from that.

Derron

(Posted 2014) [#36]

So maybe reserve a spot within the BMX-NG folder for MinGW to usw - if not existing, use the globally available one.

Just something so people can "archive" their blitzmax folder - and when unzipping it elsewhere, it still "runs" (except 64bit on 32bit)

bye
Ron

Brucey

(Posted 2014) [#37]

The latest bmk_ng will now build using an installation of MinGW on your system and ignore files in BlitzMax/bin and /lib.

* It will look first in a folder called MinGW32 in your BlitzMax folder.
* If there isn't one there, it will use the MINGW environment variable to find it.

So far it has only been tested with a 32-bit TDM (4.8.1) and a 64-bit TDM (4.8.x) MinGW install. (Note, the 64-bit TDM can build 32-bit apps *and* 64-bit apps)

As a test, I created a new, empty BlitzMax folder somewhere on my PC, and created the following folders :

/bin
/mod

The contents of the /bin folder looked like this :

bcc.exe
bmk.exe
core.bmk
custom.bmk
make.bmk

And the contents of /mod looked like this :

brl.mod
pub.mod

The MINGW variable was set to a folder on my PC containing a 32-bit TDM 4.8.1.

Some info :

.. BlitzMax\bin> bmk -v
bmk 2.22 win32-x86 / gcc 040801 (cpu x2)

.. BlitzMax\bin>bcc -v
bcc[ng] Release Version 0.21
Compile Error: Command line error

Then I did a build :

.. BlitzMax\bin>bmk makemods -a
Compiling:blitz_app.c
Compiling:blitz_types.c
Compiling:blitz_cclib.c
...
...

And finally compiling a test app (which proves final linking is working) :

.. BlitzMax\bin>bmk makeapp -a -r -t console -o ..\src\helloworld ..\src\helloworld.bmx
Compiling:helloworld.bmx
Linking:helloworld.exe

:o)

The "native MinGW" build currently only works with the new bcc. If used with the old bcc, it should simply fallback to using BlitzMax/bin and /lib. (although I haven't tested this use as thoroughly).

For the test, I downloaded everything (as zips) directly from the bmx-ng github repo : https://github.com/bmx-ng
and built bcc and bmk using a standard BlitzMax install.

YMMV, of course.

Please let me know of your successes and/or failures.
Thanks.

Hopefully this will ease transition to multi-architecture builds on Windows.

Derron

(Posted 2014) [#38]

@packaging together with MinGW - seems w32-libs and runtime is MIT, binutils and gcc are GPL.

So for runtime/w32-libs there is no need to ship the source code together with the package, binutils and GCC at least require the ability for endusers to compile their own version of that.
Dunno how "vanilla BlitzMax" handlest that - but we should be able to do it "similar".

@MinGW
To get a working "bcc-ng" you need to first install a current MinGW, copy libs, recompile all modules using the new mingw etc. Now you should be able to compile "bcc-ng" and "bmk-ng" (you should also be able to do that on another computer). Remember to uncheck "Build GUI app" in MaxIDE, we want a console app.
As soon as you have this bcc-ng, you could remove that MinGW and do like Brucey suggested.

Else you will surely receive this (or similar) when compiling:

Linking:bmk.exe
Warning: .drectve `-aligncomm:"___DTOR_LIST__",2 ' unrecognized
Warning: .drectve `-aligncomm:"___CTOR_LIST__",2' unrecognized
Warning: .drectve `-aligncomm:"___hexdig_D2A",2' unrecognized
Warning: .drectve `-aligncomm:"___mingw_usemthread_dll",2 ' unrecognized
Warning: .drectve `-aligncomm:"___mingw_gMTKeyDtor",2 ' unrecognized
Warning: .drectve `-aligncomm:"___mingw_gMTRemoveKeyDtor",2' unrecognized

Process complete

Ok, assuming you got your bcc-ng/bmk-ng compiled, you just Download the TDM (or use the one you already have installed) and do what Brucey wrote. Should work then as it did for me (but I reused an older blitzmax 1.48 setup).

But ... somehow I cannot run the bmk from console (but from within MaxIDE):

Starting program: C:\BlitzMaxNG\bin/bmk.debug.exe -v
[New Thread 3776.0x958]
~>Unhandled Exception:Attempt to access field or method of Null object
~>
q

EDIT: seems it crashes as soon as I try this:
"print processor.GCCVersion()"

EDIT2: seems "BCCVersion" calls a process which is not available - it calls "/bin/bcc" - which should not be available on Win32 platforms.

EDIT3:

Ok, BMK needs 2 fixes:

replace bmk_ng.bmx

		Local process:TProcess
		If Platform() = "win32" Then
			If processor.BCCVersion() = "BlitzMax" Then
				process = CreateProcess("gcc -v")
			Else
				process = CreateProcess(MinGWBinPath() + "/gcc -v")
			End If
		Else
			process = CreateProcess("gcc -v")
		End If

with

		Local process:TProcess
		If Platform() = "win32" Then
			'mingwbinpath already contains the path to use
			'just executing "gcc -v" results in a crash here on winXP
			process = CreateProcess(MinGWBinPath() + "/gcc -v")
		Else
			process = CreateProcess("gcc -v")
		End If

and

	Method BCCVersion:String()

		Global bcc:String
		
		If bcc Then
			Return bcc
		End If
	
		Local process:TProcess = CreateProcess(BlitzMaxPath() + "/bin/bcc")

with

	Method BCCVersion:String()

		Global bcc:String
		
		If bcc Then
			Return bcc
		End If
	
		?win32
		Local file:String = "bcc.exe"
		?Not win32
		Local file:String = "bcc"
		?
		Local process:TProcess = CreateProcess(BlitzMaxPath() + "/bin/"+file)

The last change could be also shortened to

		Local process:TProcess = CreateProcess(BlitzMaxPath() + "/bin/bcc -v")

As the error seems because "path/bcc" results in an invalid process, "path/bcc.exe" would work - and "path/bcc -v" seems to work too.

bye
Ron

Brucey

(Posted 2014) [#39]

The error(s) appear to be due to the CreateProcess() failing - because stuff is not there, or it can't find it.

Unhandled Exception:Attempt to access field or method of Null object

This is because MINGW is not set, or not pointing to a valid location.

You don't need ".exe" on the end of "bcc".

I shall add some more error checking.

However, if you try it with a correctly set up environment, it does work :-p

Derron

(Posted 2014) [#40]

are you sure about this?

		Local processB:TProcess = CreateProcess(BlitzMaxPath() + "/bin/bcc.exe -v")
If processB 
	Print "started: "+ BlitzMaxPath() + "/bin/bcc.exe -v"
Else
	Print "failed: "+ BlitzMaxPath() + "/bin/bcc.exe -v"
EndIf

		Local processA:TProcess = CreateProcess(BlitzMaxPath() + "/bin/bcc -v")
If processA 
	Print "started: "+ BlitzMaxPath() + "/bin/bcc -v"
Else
	Print "failed: "+ BlitzMaxPath() + "/bin/bcc -v"
EndIf
		Local process:TProcess = CreateProcess(BlitzMaxPath() + "/bin/bcc")
If process
	Print "started: "+ BlitzMaxPath() + "/bin/bcc"
Else
	Print "failed: "+ BlitzMaxPath() + "/bin/bcc"
EndIf

output is:

C:\BlitzMaxNG\bin>bmk.mt.exe -v
started: C:/BlitzMaxNG/bin/bcc.exe -v
failed: C:/BlitzMaxNG/bin/bcc -v
failed: C:/BlitzMaxNG/bin/bcc
started: C:/BlitzMaxNG/bin/bcc.exe -v
failed: C:/BlitzMaxNG/bin/bcc -v
failed: C:/BlitzMaxNG/bin/bcc
gcc 040801
bmk 2.22 mt-win32-x86 / gcc 040801 (cpu x1)

So this is only an invalid mingw path?

C:\BlitzMaxNG\bin>echo %path%
C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Programme\TortoiseSVN\bin;c:\MinGW\Bin;C:\MinGW\bin;C:\Programme\QT Lite\QTSystem

(double entry should not disturb functionality)

C:\BlitzMaxNG\bin>gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.8.1/lto-wrapper.exe
Target: mingw32
Configured with: ../../../src/gcc-4.8.1/configure --build=mingw32 --enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-libgomp --enable-lto --enable-graphite --enable-libstdcxx-debug --enable-threads=posix --enable-version-specific-runtime-libs --enable-fully-dynamic-string --enable-libstdcxx-threads --enable
-libstdcxx-time --with-gnu-ld --disable-werror --disable-nls --disable-win32-registry --disable-symvers --enable-cxx-flags='-fno-function-sections -fno-data-sections -DWINPTHREAD_STATIC' --prefix=/mingw32tdm --with-local-prefix=/mingw32tdm --with-pkgversion=tdm-2 --enable-sjlj-exceptions --with-bugurl=http://tdm-gcc.td
ragon.net/bugs
Thread model: posix
gcc version 4.8.1 (tdm-2)

So I assume: there is something else hidden in the bush.

PS: the null error happens in "GCCVersion" (I think) because it starts of a process - and then does not check if this is a valid handle then:

Local process:TProcess
If Platform() = "win32" Then
...
	process = CreateProcess("gcc -v")
...
End If
Local s:String

While True
	Delay 10
	'first access to process - which might be "null"
	Local line:String = process.err.ReadLine()
...

bye
Ron

Ole JR

(Posted 2014) [#41]

Seem to work here.

MINGW variable set to (old x86) C:\MinGW.

BlitzMaxNG into C:\Programming\BlitzMaxNG.

Installed MinGW-w64/TDM64 (32-bit and 64-bit)
into C:\Programming\BlitzMaxNG\MinGW32

Latest mods copied from git, bccNG & bmkNG built in "classic" BlitzMax 1.50 (threaded build).

Both installs of MinGW is tdm 4.8.1.

And the way it's set up now, I can use both "version" of BlitzMax here..

(Just tried building mods in x86/x64, thread/no-thread. 3:30 at night here)

One litte thing I've noticed is if you make a typo, ie -g x87, it will happily build the modules, and name them win32.x87.a..

Brucey

(Posted 2014) [#42]

So this is only an invalid mingw path?

No, it doesn't use the path, it uses the environment variable "MINGW". One generally needs to set this if you intend building modules from the IDE (otherwise the menus are disabled).
An NG-friendly version of MaxIDE would probably require a change to check paths in the same way as bmk does now - amongst other things like adding new build configuration options.

... and then does not check if this is a valid handle then

Indeed, which is why I added some checks for valid processes in the latest commit, reporting the errors to the console.

if you make a typo, ie -g x87, it will happily build the modules, and name them win32.x87.a..

Yes, if it doesn't find a valid match, it falls back to the default (i.e. the native architecture version of bmk/bcc). Perhaps it should rather throw an error :-)

Derron

(Posted 2014) [#43]

@Environment variable:
Is TDM intended to create that during installation? If so -- it didn't do that.
"mingwvars.bat" only sets up a path ... so hmm.

Maybe this explains why I cannot use the menus of MaxIDE (gre|ayed out).

I also do not have a "BMXPATH"-environment-variable set up - so that defaults too to check "AppDir() + /bin/bmk" for existence.

So what Did I do now: I added "BMXPATH" as environment variable (according docs this takes effect immediately but I restarted my cmd prompt). I also added the BMXPATH\bin as path - so i could call "bcc" from everywhere (thought this helps getting rid of ".exe"-needs).

Calling "bcc" from somewhere results in:

C:\>bcc
bcc[ng] Release Version 0.21
Compile Error: Command line error

I adjusted bmk_ng.bmx BCCVersion:String() to do something more:


		Local process:TProcess = CreateProcess(BlitzMaxPath() + "/bin/bcc -v")

Print "getenv BMXPATH:" + getenv_("BMXPATH")

If Not process
	Print "not able to run bcc: " + BlitzMaxPath()+"/bin/bcc -v"
	process = CreateProcess(BlitzMaxPath() + "/bin/bcc.exe -v")
	If Not process
		Print "not able to run bcc: " + BlitzMaxPath()+"/bin/bcc.exe -v"
	Else
		Print "run bcc: " + BlitzMaxPath()+"/bin/bcc.exe -v"
	EndIf
Else
	Print "run bcc: " + BlitzMaxPath()+"/bin/bcc -v"
EndIf

Here is some sample output:
(%BMXPATH% is the console access for the environmentvariable "BMXPATH")

C:\BlitzMaxNG\bin>echo %BMXPATH%
C:\BlitzMaxNG

C:\BlitzMaxNG\bin>bmk.mt.exe -v
getenv BMXPATH:C:\BlitzMaxNG
not able to run bcc: C:\BlitzMaxNG/bin/bcc -v
run bcc: C:\BlitzMaxNG/bin/bcc.exe -v
gcc 040801
bmk 2.22 mt-win32-x86 / gcc 040801 (cpu x1)

Seems the problem is something else. I also cannot remember to have BlitzMax-install doing something with environment variables.

EDIT: I also tried replacing "\" with "/" because I thought mixing both can create some trouble.

bye
Ron

Ole JR

(Posted 2014) [#44]

Might be that it falls back codewise, but the name you get on the lib is wrong.

Try this:

bmk makemods -a -g Brucey brl.blitz

Then look at the generated files.

That can't be the right behavour :)

Derron

(Posted 2014) [#45]

Which lib? I create the bmk using "vanilla BlitzMax" (to avoid problems created by bcc-ng or ng-modules).

This bmk is located within "BlitzMaxNG\bin".

So: no need to recompile "ng/mod/brl.mod/brl.blitz".

Also it does not seem like an error within "bmk" but something causing "TProcess" not to create processes if you do not append ".exe" in this case.

EDIT: I also replaced "bcc[.exe] -v" with "bcc[.exe]" but filetype-checks in createProcess are only done for MacOS.

I copied the CreateProcess code, and extended it with some print statements:

CreateProcess: C:\BlitzMaxNG/bin/bcc
     FileType: 1
       handle: 0
getenv BMXPATH:C:\BlitzMaxNG
not able to run bcc: C:\BlitzMaxNG/bin/bcc
CreateProcess: C:\BlitzMaxNG/bin/bcc.exe
     FileType: 1
       handle: 13738752
run bcc: C:\BlitzMaxNG/bin/bcc.exe
gcc 040801
bmk 2.22 mt-win32-x86 / gcc 040801 (cpu x1)

bye
Ron

Ole JR

(Posted 2014) [#46]

So: no need to recompile "ng/mod/brl.mod/brl.blitz".

We're posting at the same time and answering different things.

I only used brl.blitz as an example in reply to:

Yes, if it doesn't find a valid match, it falls back to the default (i.e. the native architecture version of bmk/bcc). Perhaps it should rather throw an error :-)

-+ Brucey +-

That was a reply to my:

if you make a typo, ie -g x87, it will happily build the modules, and name them win32.x87.a..

Derron

(Posted 2014) [#47]

I edited my post above yours. I'm online now - if you have the time for a fast chat (maybe you too celebrate the day of the Union between GDR and Germany :D).

EDIT: I replaced
BlitzMaxPath() + "/bin/bcc"
with just
"bcc"

and that worked - maybe it just works if you avoid ambiguity (within ".../bin/" there is "bcc.exe" and you call "bcc" which could also mean something within your path or so - but hmm, it also did not work BEFORE I added the path).

EDIT2: nope, ambiguity is not the reason, as then "BlitzMaxPath() + /bcc" should work - but does not.

bye
Ron

Brucey

(Posted 2014) [#48]

That can't be the right behavour :)

How you use the tools at your disposal, is completely up to you :-p