bmx-ng / bmk

The enhanced BlitzMax build program.

BMK (NG) INSTRUCTIONS

Always backup before deploying a new BMK. (Better safe than sorry!)

Compiling BMK

bmk.bmx is the main source-file.

BMK should be compiled in Non-GUI and Release mode.

Compilation with an older version of BMK:

$ mkdir -p build/
$ path/to/bmk makeapp -a -r -h -o ./build/bmk ./bmk.bmx

You can optionally specify platform and CPU during compilation, e.g.

PLATFORM="macos"
CPU="x64"
path/to/bmk makeapp -a -r -h -l $PLATFORM -g $CPU -o ./build/bmk ./bmk.bmx

You can also compile BMK in either Threaded or Non-threaded modes.

When compiled with Threading enabled, BMK will parallel compile C/C++ files when it can, scaling to the number of available cores on your system. Note : The compiled executable filename will include ".mt", which you will need to remove when deploying it in BlitzMax/bin.

When compiled without Threading, BMK will compile all files, one at a time.

Deploying BMK

The bmk executable, core.bmk and make.bmk, should be deployed in the BlitzMax/bin folder.

You can also create a custom.bmk file in BlitzMax/bin which is used to override built-in compiler options, such as optimisations. (see "Using custom.bmk" below)

On Linux and MacOS systems, you may also optionally deploy config.bmk. This provides settings for Cross-Compiling modules and applications for Win32 targets. If you intend to use this, please check the file for any system-specific configuration options you need to supply.

Using custom.bmk

This file allows you to override the default compiler options BMK uses.

The format is :

The normal command is "addccopt", but all valid commands are listed here :

addccopt             - for all platforms and processors
addlinuxccopt        - Linux specific option
addwin32ccopt        - Win32 specific option
addmacccopt          - MacOS specific option
addmacx86ccopt       - MacOS x86 specific option
addmacppcccopt       - MacOS ppc specific option

The following option names will override the default settings appropriately

optimization - Optimize level. The default is -Os (optimize for size) arch - The processor architecture. The default -march=pentium math - The floating point unit.

If you want a value to contain spaces, wrap it in double-quotes (")

See the gcc manual for more options. (hint: google for "man gcc", is useful).

Cross-Compiling

BMK supports compiling of Win32 binaries and modules on MacOS and Linux systems.

You can download all the necessary packages from the following location :

    http://brucey.net/programming/blitz/mingw/

Running BMK

You can obtain the current version of BMK with :

bmk -v

Running BMK with no options will produce a basic Usage guide.

bmk's Issues

Fails to include the .ico file with threading enabled?

Windows 10 x64

As stated, when enabling threading or debug the *.ico file seem to be ignored.

File specific configuration command similar to ModuleInfo "string"

For now BMK handles "ModuleInfo" in module files. But I think it would be nice if certain features are also available to "normal" source files.

Assume you do not want to use a module a module (needs install to BlitzMax/mods) but rather use it as normal source file. For now BMK/BCC only handle "ModuleInfo" (eg. ModuleInfo "CC_OPTS: -fexceptions").
BMK allows certain stuff (cc opts) in "custom.bmk". But this is then a global configuration, no "app individual" one.

Maybe we should introduce "FileInfo" which does a similar job - but on a file rather a complete module or globally (via custom.bmk).

Compilation + Linking times longer with specific frameworks...

Since 1ca5841 the compilation takes longer if you use certain modules as framework:

Framework wx.wxApp

takes some minutes to compile for a simple editor sample

while

Framework Brl.StandardIO
Import wx.wxApp

compiles still fast (of course linking takes still a while as some files are linked nonetheless ...)

Maybe "Framework"-handling does some recursive thing - because it takes the longer the "more complex" the "Framework"-module is (wx is a bigger thing.)

Crosscompiling for Win32 - outdated

Next to the small spelling error in the readme ("relese") I think the "cross-compiling" section could need an overhaul. Just to use a more current MinGW.

gcc is now PIE on latest linux (ubuntu)

Hi,

I've just install NG on a 32-bit ubuntu 18.04 (bionic) which is nice but I found it compiles executables as shared libraries, you can run these from the Terminal but not double-click from the file manager. I found out this is due to position-independent executables (pie) now being enabled by default in GCC.

There's two solutions mentioned here https://wiki.ubuntu.com/SecurityTeam/PIE but I could only get the no-pie one to work. I tried adding to custom.bmk which only seems to work for addlinuxccopt, I get nothing with addlinuxldopt. The problem is this is a ld option and doesn't work as cc, so I had to edit bmk_util.bmx adding at line 446:
sb.Append(" -fPIE -no-pie")
There's also -fPIC which works too but it seems to be related to using shared libraries whereas PIE is for executables. I tested and it doesn't affect earlier distros.

When I tried the -r option (relocatable object) it wouldn't build, I put it in the same place in bmk_util.bmx and got the warning:
using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking.
So it seems the more complex option of the two.

"bmk makemods -r -l android -g armeabi" tries to use x86-interface

Running

$  ./bmk makemods -r -l android -g armeabi

leads to

...
[ 54%] Processing:sdlmax2d.bmx
Compile Error: Can't find interface for module 'brl.blitz'
[/blitzkeywords.debug.android.x86.i;9;0]
Build Error: failed to compile (65280) /BlitzMaxNG/mod/sdl.mod/sdlmax2d.mod/sdlmax2d.bmx

Somehow it uses blitzkeywords.debug.android.x86.i instead of blitzkeywords.release.android.armeabi.i

Seems as bmk changes opinion about release/debug and processor inbetween.

Edit:
Seems that is actually a "bcc"-issue, not a "bmk"-one.

Cannot compile lua.bmx

Building Modules
[ 45%] Processing:debugger_mt.stdio.bmx
[ 46%] Processing:sample.bmx
[ 46%] Processing:d3d7max2d.bmx
[ 46%] Processing:d3d9max2d.bmx
[ 46%] Processing:data.bmx
[ 46%] Processing:directsoundaudio.bmx
[ 47%] Processing:dxgraphics.bmx
[ 47%] Processing:font.bmx
[ 47%] Processing:hook.bmx
[ 47%] Processing:keycodes.bmx
[ 47%] Processing:linkedlist.bmx
[ 47%] Processing:intmap.bmx
[ 48%] Processing:objectmap.bmx
[ 48%] Processing:ptrmap.bmx
[ 48%] Processing:stringmap.bmx
[ 48%] Processing:math.bmx
[ 48%] Processing:pixel.bmx
[ 49%] Processing:random.bmx
[ 49%] Processing:driver.bmx
[ 49%] Processing:threads.bmx
[ 49%] Processing:gadgetitem.bmx
[ 49%] Processing:guifont.bmx
[ 49%] Processing:win32maxguiex.bmx
[ 50%] Processing:directx.bmx
[ 50%] Processing:freeaudio.bmx
[ 50%] Processing:glew.bmx
[ 50%] Processing:joystick.bmx
[ 50%] Processing:libjpeg.bmx
[ 50%] Processing:lua.bmx
Compile Error: Invalid Pointer type.
[/Volumes/Irravonia/BlitzMAX/NG/mod/pub.mod/lua.mod/lua.bmx;268;0]
Build Error: failed to compile /Volumes/Irravonia/BlitzMAX/NG/mod/pub.mod/lua.mod/lua.bmx
Process complete

Faulty code:

Rem
bbdoc: see <a href="../lua-5.1.4/doc/manual.html#lua_getinfo">Lua Reference Manual</a>
end rem
  Function lua_getinfo:Int (lua_state:Byte Ptr, what$z, ar:lua_Debug Ptr)    ' no ~0 expected

I wonder if this is due to the fixes on bmx-ng/bcc#200 and bmx-ng/bcc#202

Does not auto-compile D3D7Max2DDriver

Downloaded the latest "32+64bit windows release" and tried to compile my game for 64bit release:

[  0%] Processing:blitz.bmx
[  0%] Processing:appstub.bmx
[  0%] Processing:sample.bmx
[  0%] Processing:font.bmx
[  0%] Processing:hook.bmx
[  0%] Processing:keycodes.bmx
[  0%] Processing:intmap.bmx
[  0%] Processing:objectmap.bmx
[  0%] Processing:ptrmap.bmx
[  0%] Processing:stringmap.bmx
[  0%] Processing:math.bmx
[  1%] Processing:pixel.bmx
[  1%] Processing:random.bmx
[  1%] Processing:driver.bmx
[  1%] Processing:threads.bmx
[  1%] Processing:glew00.bmx
[  1%] Processing:glew01.bmx
[  1%] Processing:glew02.bmx
[  1%] Processing:glew03.bmx
[  1%] Processing:glew04.bmx
[  1%] Processing:glew05.bmx
[  1%] Processing:glew06.bmx
[ ...]
[ 28%] Processing:main.bmx
Compile Error: Identifier 'd3d7max2ddriver' not found.
[TVTower.git/source/main.bmx;3873;0]
Build Error: failed To compile (-1) TVTower.git/source/Main.bmx
Process complete

So while it compiled some modules, it somehow did not compile d3d7max2ddriver.mod.

Without having had the time now I assume it has to do with the fact of using it in the "main.bmx" while it originally was imported in another file.

BMK makemods - error reading from stream

On that particular Windows 7 computer (which has issues with the timer ....) I sometimes have "error reading from stream" when compiling the modules (bmk makemods -a -r brl). The error either happens right inbetween (so output is something like "[ 3%] Processing:driv error reading from streamer" - so mixed "driv..er") or right after such a processing line.

I then run the command again - and it fails at another module or happily continues until it finished. So something seems to interrupt file access. It is a intel based computer, maybe threading issues or so?

Allow provision of own manifest file

Currently, bmk automatically creates a manifest file and resource for a Win32 GUI app using information provided by an application settings file, unless told to do otherwise (-nomanifest)

It would be nice if the user could simply provide their own manifest - in order to set up custom stuff such as UAC, signing, etc.

A resource file is generated to include the generated manifest. The resulting object is then linked into the binary.

I suggest we still create the resource, and use the user-provided manifest in place of generating one.

Are extern types working just yet?

Not sure if the bmk or bcc :/
Rather that show you my own code its easier to use the example in the docs under 'Interfacing with C and other languages' with ( a fixed version of ) the c++ example on that help page to see any errors.

Quick Build not picking up changes to incbin content

As per the title, after adding a couple of new incbins to maxide, with Quick Build enabled, the build did not generate/compile the incbin object file, leading to undefined refs.

Absolute file paths not working.

Add support for absolute paths on import, include and incbin.

Faster compiling

I'm not sure on the method used to check if a file needs compiling or not, I'd expect the date stamps difference between the .bmx and corresponding output .c file?

If that's the case then it would be possible to also check the date stamps of the .c and its corresponding .o output file to further remove redundant compiles?

Pie commit - binaries now classified as "shared library"

The latest commit (pie as default: 8fc8042

leads to an error on my linux box:

[100%] Linking:GenusPrime.debug
g++ -m64 -pie -fpie -pthread -o /home/ronny/Arbeit/Programmieren/Projekte/GenusPrime/GenusPrime.debug /home/ronny/Arbeit/Programmieren/Tools/BlitzMaxNG/tmp/ld.tmp -L/usr/X11R6/lib -L/usr/lib -L/home/ronny/Arbeit/Programmieren/Tools/BlitzMaxNG/lib
collect2: fatal error: ld terminated with signal 6 [Abgebrochen]
compilation terminated.
/usr/bin/ld: ld: wcsrtombs.c:94: __wcsrtombs: Zusicherung »data.__outbuf[-1] == '\0'« nicht erfüllt.
Build Error: Failed to link /home/ronny/Arbeit/Programmieren/Projekte/GenusPrime/GenusPrime.debug
Process complete

Incbin issue with embedded includes.

I noticed with the new incbin feature if you have the following for example

'sub.bmx
Incbin "default.dat"
do.init("incbin::default.dat")

and then you later include that file that has the incbin
'main.bmx
include 'sub,bmx'

it then results in the following message 'sub.bmx.debug.win32.x64.incbin.c: No such file or directory'
as it has been created as - main.bmx.debug.win32.x64.incbin.c

Fail to build bmk as x64 on windows 8.1

bcc -v 0.57
bmk -v 3.0
mingw 4.8.1 (x64)

Trying to build bmk as x64:

[ 90%] Processing:bmk_ng_utils.bmx
Compile Error: Duplicate identifier 'mingw'.
[E:/BlitzMaxNG/src/bmk/bmk_config.bmx;74;0]
Build Error: failed to compile (-1) E:/BlitzMaxNG/src/bmk/bmk_config.bmx

Argument list too long

From @Leushenko on January 20, 2016 21:53

Following error when compiling:

sh: /usr/bin/gcc: Argument list too long
Build Error: failed to compile (32256) /Users/alex/Projects/...<etc>

No further details offered by the compiler. This is at around 63% completion.

Copied from original issue: bmx-ng/bcc#156

Custom.bmk should override environment variables

Current state:

• if an environment variable is set (eg "android_sdk") then this is used instead of a value defined in custom.bmk

So if you use another NDK/SDK for another programming environment, you might run into trouble.

What might be better?
Use the environment variables as backup if no setup was done in custom.bmk

Function CheckAndroidPaths()
    ' check envs and paths
    local androidHome:string = processor.Option("android.home", getenv_("ANDROID_HOME")).Trim()
    If Not androidHome Then
        Throw "ANDROID_HOME or 'android.home' config option not set"
    End If
    putenv_("ANDROID_HOME=" + androidHome)
    globals.SetVar("android.home", androidHome)


    Local androidSDK:String = processor.Option("android.sdk", getenv_("ANDROID_SDK")).Trim()
    If Not androidSDK Then
        Throw "ANDROID_SDK or 'android.sdk' config option not set"
    End If
    putenv_("ANDROID_SDK=" + androidSDK)
    globals.SetVar("android.sdk", androidSDK)


    Local androidNDK:string = processor.Option("android.ndk", getenv_("ANDROID_NDK")).Trim()
    If Not androidNDK Then
        Throw "ANDROID_NDK or 'android.ndk' config option not set"
    End If
    putenv_("ANDROID_NDK=" + androidNDK)
    globals.SetVar("android.ndk", androidNDK)


    Local androidToolchainVersion:String = processor.Option("android.toolchain.version", getenv_("ANDROID_TOOLCHAIN_VERSION")).Trim()
    If Not androidToolchainVersion Then
        Throw "ANDROID_TOOLCHAIN_VERSION or 'android.toolchain.version' config option not set"
    End If
    putenv_("ANDROID_TOOLCHAIN_VERSION=" + androidToolchainVersion)
    globals.SetVar("android.toolchain.version", androidToolchainVersion)


    Local androidPlatform:String = processor.Option("android.platform", getenv_("ANDROID_PLATFORM")).Trim()
    If Not androidPlatform Then
        Throw "ANDROID_PLATFORM or 'android.platform' config option not set"
    End If
    putenv_("ANDROID_PLATFORM=" + androidPlatform)
    globals.SetVar("android.platform", androidPlatform)


    Local androidSDKTarget:String = processor.Option("android.sdk.target", getenv_("ANDROID_SDK_TARGET")).Trim()
    putenv_("ANDROID_SDK_TARGET=" + androidSDKTarget)
    ' NOTE : if not set, we'll try to determine the actual target later, and fail if required then.
    globals.SetVar("android.sdk.target", androidSDKTarget)


    Local antHome:String = processor.Option("ant.home", getenv_("ANT_HOME")).Trim()
    If Not antHome Then
        ' as a further fallback, we can use the one from resources folder if it exists.
        Local antDir:String = RealPath(BlitzMaxPath() + "/resources/android/apache-ant")

        If FileType(antDir) <> FILETYPE_DIR Then
            Throw "ANT_HOME or 'ant.home' config option not set, and resources missing apache-ant."
        Else
            antHome = antDir.Trim()
        End If
    End If
    putenv_("ANT_HOME=" + antHome)
    globals.SetVar("ant.home", antHome)


?Not win32  
    Local pathSeparator:String = ":"
    Local dirSeparator:String = "/"
?win32
    Local pathSeparator:String = ";"
    Local dirSeparator:String = "\"
?
    Local path:String = getenv_("PATH")
    path = androidSDK.Trim() + dirSeparator + "platform-tools" + pathSeparator + path
    path = androidSDK.Trim() + dirSeparator + "tools" + pathSeparator + path
    path = androidNDK.Trim() + pathSeparator + path
    path = antHome.Trim() + dirSeparator + "bin" + pathSeparator + path
    putenv_("PATH=" + path)

End Function

If you are "d'accord" with the changes, I would create a pull request out of it.

Am not sure whether "putenv_" is needed in all cases (does bmk/bcc use that setup later on?). All in all the change is just for the process ("local scope") so this does not really matter.

Another bug squashed in it is the "trim()". The current revision does not trim the environment-variables. so in my case some "move to begin of line"-character is read. I defined my environment variables using .bashrc (export varname varcontent). This has lead to trouble - until I trimmed the content of the variable (it is used ìn ConfigureAndroidPaths()).
While the problem is created by me (using .bashrc wrongly or so...) it is a convenience increase to just take care of it.

bmk makelib produces DLL with no exported functions

Hi Brucey,

I've been trying to build DLLs from bmx-ng using Sweenie's little MakeDLL program, with no joy, as documented here:

http://www.blitzbasic.com/Community/posts.php?topic=50045

However, using what turns out to be vanilla bmk's (undocumented?) 'makelib' option, I can build a working 32-bit DLL using this process:

http://mdt.bigbang.free.fr/blitz3dfr/_fofo/index.php?topic=2703.0

Trying the same from bmx-ng's bmk, though, I get a DLL, but it doesn't contain the exported function.

I'm wondering if you might be able to get this working in bmx-ng at some point (and maybe 64-bit DLLs too?). In vanilla, you just define the exported functions in mydll.def and call bmk makelib mydll.bmx -- had no idea it was so easy! Of course, it produces 32-bit DLLs only.

Here are a couple of test setups:

1. Working example (with command-line binaries to show working), built with vanilla:

http://www.hi-toro.com/blitz/temp/makelib32.zip

2. Non-working example, giving broken DLL with bmx-ng:

http://www.hi-toro.com/blitz/temp/makelib_fail.zip

See info.txt in each archive for relevant, er, info!

bmk fails with "illegal instruction"

When my Linux dev box died some time ago, I switched to an older setup with an AMD Phenom II X4 965 cpu. Upgraded to latest bmk, bcc & pup/brl.mod. And my bmx_ng setup didn't work anymore..

After reinstalling different Linux distro's, pulling some hair, THEN digging around on google, I found that this (oldish) cpu doesn't like the commit dated may 21, 2016 (Added default simd cc_opt for x64 (-msse4)).

Commenting out the whole line in 'make.bmk' made the modules/exe's work.
Then I tried with different -msse(X), and the highest working was -msse4a.

Imported resource .o in module not present in exe

A binary .o imported directly by a module is added to the module static archive, but is not subsequently applied to the final binary.

Perhaps it would be better to add the import to the interface (.i) and then apply the actual import when the exe is linked (in the same way as -l is applied) ?

DLLs require access to libgcc_s_sjlj-1.dll and libwinpthread-1.dll

A DLL built with NG requires the files "libgcc_s_sjlj-1.dll" and "libwinpthread-1.dll".
If you MinGW installation is reachable through a set PATH it will run of course. But on other systems you need to pack these files next to the NG-built-DLL.

Is there a way to circumvent that? By including some files straight into the DLL source before building? Looks a bit "cluttered" to have to supply multiple files - not to talk about the uncertainty of missing other DLL files.

Implement "speed-up"

The old bmk had an "experimental" feature which used a shadow interface file to determine whether any public apis for a given .bmx source had changed.

The idea is that you don't need to recompile if your dependent source only changed internal code, and not any public apis.

So for example, I have an app that depends on the meh.blah module. If I make a change to the internals of a function in the module, that doesn't require me to recompile my app, only re-link the new .a file.
However, if I add a new function to the module, I will need to recompile the app because of the public interface changes.

BMK 3 removed "pragma"

Since "Chirpy"-release 4d77b40 BMK does no longer take care of pragmas within the files:

'@bmk bla(param)

Reason: @woollybah just removed that portion when redoing parts of BMK.

Recompile code if ".bmx/sourcename.bmx. ... .s" is found

Not directly an issue, but maybe creating trouble which is not needed:

If cou compile with vanilla bmk, the the hidden folder .bmx contains the cache files of the compilation, for release builds on linux it is:
sourcename.bmx.release.linux.x86.i
sourcename.bmx.release.linux.x86.o
sourcename.bmx.release.linux.x86.s

When building with "NG" it gets:
sourcename.bmx.release.linux.x86.c
sourcename.bmx.release.linux.x86.h
sourcename.bmx.release.linux.x86.i
sourcename.bmx.release.linux.x86.o

See the difference is ".s" and ".c/.h".

Now to the problem: if bmk comes across a newly created file (newer than the source) it tries to use the existing files ("cache"). If your old code was compiled using the vanilla BMX, you will run into some errors blaming undefined things etc. Of course it is the same "vice versa".
This really gets important, if you use a source code from multiple projects import "../lib/file.bmx".

Suggestion: next to the file date check it should check for the existence of a ".s"-file and if existing, unlink that cachefiles and recompile the corresponding sourcefile.

Disable "Overload warnings" as default ?

Blitzmax is intented as a "beginners friendly language". So I think it becomes a hassle to cast down things which you as "normal developer" would think should just work (even if mathematically incorrect).

Eg. I often use "sin()" + "millisecs()" to make something fade out/fade in - aka "blink".
SetAlpha 0.7 + 0.3 * Sin(Millisecs()*0.25) (or so). Now "sin()" returns a double while SetAlpha expects a float. To get rid of that particular "error" (as default it is an error, not a warning...) you need to wrap either "all in all" or at least the particular sin() call to be casted into an float value.

In other cases I have a Function Draw(x:int, y:int) and call it like Draw(x + 0.5*width, y) (so "aligning" stuff). NG blames that I needed to pass an integer (which is not wrong, just "undesired"). The function definition is made this way to automatically expose the information: fractions are ignored, we draw at fixed integer points.

If you wrote all functions on your own, then this wont be an issue. I am talking about "vanilla modules". If there was a
Function SetAlpha(value:float) and a Function SetAlpha(value:double) then the default user won't see the message. It would just work. (PS: you could just use the second variant and silently cast down to a float within... but maybe this is dirty).

For custom classes (done by the developer) this is a different story as the developer knows if they needed to handle "float" differently to "int" or "double".
What reasons are there to not silently accept "doubles" when "floats" are requested - is it just the fact that it is no longer the same number (what is passed to the function is no longer what is received in the function) ?

I am asking as said above: it is a beginners language which allows for advanced usage. Maybe the advanced usage should be "to enable" instead of the "beginner usage".

TImageFont.CreateDefault() end with EXCEPTION_ACCESS_VIOLATION

Windows 10 x64

Everything updated (bmk v3.26 & bcc v0.97)

This oneline program crashes with EXCEPTION_ACCESS_VIOLATION
Graphics (800, 600, 0)

Stepping through the code with debug:

Function CreateDefault:TImageFont()
  Local font:TImageFont=New TImageFont
  font._glyphs=New TImageGlyph[96]
  Local pixmap:TPixmap=TPixmap.Create( 96*8,16,PF_RGBA8888 )

  Local p:Byte Ptr=IncbinPtr( "blitzfont.bin" )  <-- This seem to be a NULL pointer
  For Local y=0 Until 16
    For Local x=0 Until 96
      Local b=p[x]            <-- Crash here
	For Local n=0 Until 8
	  If b & (1 Shl n) 
            pixmap.WritePixel x*8+n,y,~0
	  Else
	    pixmap.WritePixel x*8+n,y,0
	  EndIf
	Next
  Next
	p:+96
Next

possible 'remove .x file' solution

Just an idea...
I guess this relates a lot more to the Windows builds.
What are your thoughts on having what would be in the .x file defined after the Extern definition?
Such as

Extern
	Function GetWindowLongPtr:Byte Ptr(hWnd:Byte Ptr, index:Int)"Win32" = "LONG_PTR GetWindowLongPtr(HWND, INT)"
EndExtern

or keep the 'max syntax and/or the 'max data types.

Extern
	Function GetWindowLongPtr:Byte Ptr(hWnd:Byte Ptr, index:Int)"Win32" = "GetWindowLongPtr:BBBYTE*(BBBYTE*, INT)"
EndExtern

Would something like that allow to remove the .x file?

BMK makelib creates .DLL and .a file

When building a .DLL with bmk then it creates an .a file too - should this be kept this way as default (as the .a file should not be needed) or should it be placed similar to other temporary stuff within the ("hidden") folder .bmx?

BMK module compilation skips modules

C:\Programmieren\BlitzMaxNG\bin>bmk makemods -d -a -g x64 brl
[  0%] Processing:blitz.bmx
[  0%] Processing:debugger_mt.stdio.bmx
[  0%] Processing:sample.bmx
[  0%] Processing:errors.bmx
[  0%] Processing:iterator.bmx
[  1%] Processing:d3d7max2d.bmx
[  1%] Processing:data.bmx
[  1%] Processing:font.bmx
[  1%] Processing:hook.bmx
[  1%] Processing:keycodes.bmx
[  1%] Processing:intmap.bmx
[  2%] Processing:objectmap.bmx
[  2%] Processing:ptrmap.bmx
[  2%] Processing:stringmap.bmx
[  2%] Processing:math.bmx
[  2%] Processing:pixel.bmx
[  2%] Processing:random.bmx
[  3%] Processing:common.bmx
[  3%] Processing:driver.bmx
[  3%] Processing:threads.bmx
[  3%] Processing:d3d.bmx
[  3%] Processing:freeaudio.bmx
[  6%] Processing:libjpeg.bmx
[  6%] Processing:lua.bmx
[  6%] Processing:oggvorbis.bmx
bcc[ng] Release Version 0.93
[  6%] Processing:openal.bmx
[  7%] Processing:stbimage.bmx
[  7%] Processing:com.bmx
[  7%] Processing:commdlg.bmx
[  7%] Processing:gdi32.bmx
[  8%] Processing:kernel32.bmx
[  8%] Processing:shell32.bmx
[  8%] Processing:user32.bmx
[  8%] Processing:winmm.bmx
[  8%] Processing:zlib.bmx
[  8%] Processing:appstub.bmx
[  9%] Processing:collection.bmx
[  9%] Processing:map.bmx
[  9%] Processing:stringbuilder.bmx
[  9%] Processing:commctrl.bmx
[ 10%] Processing:richedit.bmx
[ 10%] Processing:linkedlist.bmx
[ 10%] Processing:socket.bmx
[ 10%] Processing:stream.bmx
[ 10%] Processing:enet.bmx
[ 10%] Processing:source.bmx
[ 11%] Processing:libpng.bmx
[ 11%] Processing:queue.bmx
[ 11%] Processing:win32.bmx
[ 11%] Processing:freetype.bmx
[ 11%] Processing:audiosample.bmx
[ 12%] Processing:bank.bmx
[ 12%] Processing:list.bmx
[ 12%] Processing:endianstream.bmx
[ 12%] Processing:event.bmx
[ 12%] Processing:pixmap.bmx
[ 12%] Processing:ramstream.bmx
[ 13%] Processing:reflection.bmx
[ 13%] Processing:socketstream.bmx
[ 13%] Processing:textstream.bmx
[ 13%] Processing:threadpool.bmx
[ 13%] Processing:d3d7.bmx
[ 13%] Processing:d3d9x.bmx
[ 14%] Processing:dd.bmx
[ 14%] Processing:dsound.bmx
[ 14%] Processing:collections.bmx
[ 14%] Processing:audio.bmx
[ 14%] Processing:bankstream.bmx
[ 14%] Processing:freetypefont.bmx
[ 15%] Processing:httpstream.bmx
[ 15%] Processing:jpgloader.bmx
[ 15%] Processing:maxlua.bmx
[ 15%] Processing:oggloader.bmx
[ 15%] Processing:pngloader.bmx
[ 15%] Processing:standardio.bmx
[ 16%] Processing:stbimageloader.bmx
[ 16%] Processing:timer.bmx
[ 16%] Processing:wavloader.bmx
[ 16%] Processing:bmploader.bmx
[ 16%] Processing:filesystem.bmx
[ 17%] Processing:openalaudio.bmx
[ 17%] Processing:tgaloader.bmx
[ 17%] Processing:d3d9.bmx
[ 17%] Processing:directx.bmx
[ 17%] Processing:basic.bmx
[ 17%] ProcessCompile Error: Can't find interface for module 'brl.random'
[C:/Programmieren/BlitzMaxNG/mod/brl.mod/basic.mod/basic.bmx;18;0]
ing:maxutil.bmx
[ 18%] Processing:sBuild Error: failed to compile (-1) C:/Programmieren/BlitzMaxNG/mod/brl.mod/basic.mod/basic.bmxystem.
bmx

C:\Programmieren\BlitzMaxNG\bin>

It also seems to eat some text output ("ing:maxutil.bmx"" "bmxystem.bmx"). I somehow think the threading is guilty.

bmk "makemods -l LLL" does not create "blitz.mod/blitz.x.LLL.*.i|a"

When trying to recompile my modules I came across this odd behaviour (checked previous BMK revisions up to begin of june: they behave the same).

When running ./bmk makemods -a -r -l linux it compiles all modules .. but it does not create the file blitz.mod/blitz.release.linux.x86.i/.a.
All other modules get their "modulename.release.linux.x86.i/.a" created.

When running the same command without "-l linux", it compiles too - but this time creates the desired file.

When running ./bmk makemods -a -r -l linux brl (to limit to "brl.mod") it creates the file.

Happens to other -l-options (tested "android") too.

New commands to cleanup/remove .bmx in modules/project

During "cleaning up" my project folders to avoid potential problems when trying to find bugs in BMK I thought BMK could benefit from a commands: cleanmods and cleanapp

What it does

... is something similar to "make clean": it removes all the stuff which a "makemods" or "makeapp" would create. This also includes removing the ".bmx" folders if they are empty afterwards (so only remove, if you did not have custom stuff in it - or files from a vanilla-blitzmax installation).

Intention

So ideally you could run
bmk cleanapp path/to/app/TVTower.bmx
and it removes all precompiled stuff - so I could "zip" it and just get a "compile your own game"-archive without any precompiled stuff which needs a loot of space in the archive.

Notes

As it is more than deleting the .bmx directory right next to a project file things might not be a simple 3-liner. It would need to do a similar thing than the "dependency graph" bmk currently is building up during building stage.
For cleanapp I would suggest to only remove "project stuff", not imported modules (which might have been autobuild by a previous makeapp - so this isn't exactly cleaning up what it has produced, think that would be ok).

Extern function in conditional imports fail

From @GWRon on May 27, 2016 8:54

When compiling on Linux, the linking fails. Conditionals itself work (so when removing that conditional around the import, the print's are executed correctly.

extern.bmx

SuperStrict
Framework Brl.StandardIO
?Linux And Not Android
Import "extern.c"
?

?Linux And Not Android
Print "linux but not android"
?

?Not Android
Print "not android"
?



?Linux And Not Android
Extern
    Function bbRun:Int()
End Extern


Type TTest
    Method Run()
        bbRun()
    End Method
End Type
?

Output:

Building extern
[ 77%] Processing:extern.bmx
[ 88%] Compiling:extern.bmx.console.release.linux.x86.c
[100%] Linking:extern
/test/.bmx/extern.bmx.console.release.linux.x86.o: In function `__m_extern_TTest_Run':
extern.bmx.console.release.linux.x86.c:(.text+0x21): undefined reference to `bbRun'
collect2: error: ld returned 1 exit status
Build Error: Failed to link /test/extern
Process complete

Adjusting the import-conditional to only be ?ǹot android it compiles and links fine.

Copied from original issue: bmx-ng/bcc#195

BMK gcc debug option

Hi,

it might be useful to have 'gcc' parameter in BMK, that would display the path or version of gcc used to compile modules/apps for debugging purposes.

-Henri

bmk - Unexpected character : ?

Building the new bmk and deploying it results in the following on Windows, using newly updated make.bmk with this base release package and updated modules https://github.com/bmx-ng/bmx-ng/releases/tag/v0.93.3.21.win32.x64

Building Modules
Unexpected character : ?
Process complete

Can't import C functions from Visual Studio library

I have started moving my application over to BlitzMaxNG to make a 64-bit build. I am unable to import a Visual Studio library in BMXNG. I understand that the C++ classes in Visual Studio libraries are not compatible with the GCC compiler. However, it should still be possible to import C functions from a Visual Studio library, as BlitzMax can.

Demo:
http://www.leadwerks.com/buildtest.zip

Forum thread here:
http://www.blitzmax.com/Community/posts.php?topic=107107

"compilation" times longer because of file lookups

Not directly a bug or so ... but a notice.

On each compilation process BMK is comparing filetimes of all included and imported source files.

The more your project imports/includes (module and source file wise) the longer it takes.

I cannot come up with a general solution to this problem. I understand that the problem arises from the feature of dynamic compilation of requested modules.

One suggestion is to create an additional file in .bmx containing the last saved filename (not needed) and having a filetime of that modified file.
This would need a modified MaxIDE (file creation on "save"). It also would lead to problems when using other (text) editors.

So a better option would be to have a list of files per directory and let the system (OS) return the newest/latest touched file (timestamp).
Problem here is: I am not sure whether such a system call exists. Spawning processes ("ls") is creating to much overhead.
If there was an command ignoring provided filelists we would have to check if the newest is contained in our sources list...and if not, fall back to current approach.

For modules there is a potential solution: fileMtime of directories should change on creation of new files (directory index changes). So as we know that modules' .bmx-directory is only used by that module (compared to .bmx of a directory containing multiple projectXYZ.bmx) we could use that for our advantage.
When compiling a module a special file is unlinked (if existing) and regenerated...this should then trigger an index change (might need a clearstats call inbetween).
If that is not the case then we need up to two files (comptime1 and comptime2). Each compilation removes the one file and creates the other one...

What does this do? It moves the filetime checks from per-project-compilation to a per-module-compilation. Projects are surely leas often compiled than projects.

Any other ideas?

Quick-scan/non-Quick-scan does not recognize changes to C files

I have a project.bmx which imports main.bmx which imports sub.bmx which imports sub_child1.bmx

sub_child1.bmx imports "sub_child1.c" (so not a bmx file).

Any change to the "sub_child1.c" file was ignored by BMK and did not lead to a recompilation of "sub_child1.bmx" (and so also not of the other files).

Happens to "quick scan" and "not quick scan" mode here (so in "non-rebuild" mode).

BMK makelib - not able to avoid .def generation (no -def relay)

When telling BMK to "makelib" a sharedlib then it automatically passes "-def" to BCC calls. Creating .def files even if not desired so.

Maybe we should consider adding "nodef" similar to "nomanifest" or "nostrictmode". This way we could - for whatever reason it might be desired - disable .def generation from within the initial BMK build call.

Your commit on 31. Aug breaks compiling on vanilla blitzmax.

Commit 'Added universal ios builds (x86+x64, armv7+arm64). '

bmk_modutil.bmx line 138 'Select file.ExtractExt(file)'

Compile error: Identifier 'ExtractExt' not found.

Linux Mint 17.2 x64

Compiling 64bit and then 32bit skips compilation

Tried on windows:
If you compiled something with 32 bit (in my case it wasn't even a successful build), switched then to 64 bit, compiled (successfully) and then switch to 32bit followed by a "compile and run" in MaxIDE, it will just launch the existing binary which was compiled with 64bit.
Maybe break with vanilla compatibility and append .x64 to the application name? (or .x86 if we default to x64)

bmk built for x64 on windows wont work

Not really a big problem, but this is an issue I've always(?) had.
On windows (10), whenever I try to use bmk built for x64 it just hang on the first file it tries to compile.
Example:

bmk makemods -a
[  0%] Compiling:dLinearAlgebra.cpp

Have to Ctrl-C

Bad escape sequence in string

I can no longer compile bmk, as I am getting afromentioned error on this line:

bmk/bmk.bmx

Line 489 in 8fb293d

stream.WriteString("SET PARENT=%~dp0~n~n")

Win32: resource file check in wrong directory

When compiling with the current BMK it should create a resource file and link it in the final gui executable.

Currently it does something wrong:

• it checks for files in the project directory (for unsaved this is tmp...which makes it work in simple tests :-))
• it creates files in the tmp directory, not the project directory

So while it creates projectname.cpu.o files in blitzmax/tmp it should create these files in projectdirectory/...

Also I am not sure if it links the .o file if max_lnk_time is older than the FileTime(opt_outfile) or opt_all is false. I think it should link everytime (depslis.AddLast()...?) - even if there is nothing to do except "link everything together".

Importing non existant files within a module compile

Not exactly a show stopper, but inside a module source... if you import a non-existing file ( other than a non-existing .bmx file ) then the module will compile without error.

Quick compile ignores changes in included files of included files

What happens?

When changing content of an included file included from another file, this does not trigger recompilation.

How to replicate

• create a file "test.bmx"

SuperStrict

include "test_include.bmx"
print "finished"

• create a file "test_include.bmx"

include "test_include_include.bmx"

• create a file "test_include_include.bmx"

print "I should trigger recompilation on changes"

Compile "test.bmx" and then change test_include_include.bmx. When now trying quick compile it does not recompile because it does not check the file date of that file.

Why?
bmk_make.bmx: Method CalculateDependencies() does not recursively check all includes/incbins. So when compiling test.bmx it just checks the timestamp of test_include.bmx" (and sets the timestamp of test.bmx accordingly) but skips *test_include_include.bmx.

How to solve:

For each included file the it should check the incbins like it does now but for each included file it should run that same function to load their incbins/includes (which then trigger that include/incbin-check again).
Short: needs some recursive functionality.

Refactor for speedup - deletions

At the moment, bmk deletes files before handing off to a threaded task to regenerate them.
It would probably be better if the delete was done as part of the task, which would be things far less linear.

Extend pre.bmk and post.bmk support to be project specific

For now BMK tries to run "pre.bmk" before compilation and "post.bmk" after compilation.

Sometimes you have multiple "tools" in a single folder (forwhatever reason) or you might have different "main files" doing small adjustments (demo, release, test...).
To avoid having all these files use the same "pre.bmk" or "post.bmk" it would be a simple but handy addition to BMK to support "mysourcefile.pre.bmk" and "mysourcefile.post.bml".

Generated DLLs not loadable

Dunno what changed ... but with current BMK, BCC, pub.mod and brl.mod I am no longer able to load the generated DLLs.

It works when using 3rd party DLL files - so something must be "mixed up".

It also has worked some weeks ago - means I am a bit clueless what could be the culprit now.
There might have been Windows updates on that computer (3rd party, not under my control).

dll.bmx

SuperStrict

Framework brl.standardIO

Global versionPtr:Byte Ptr = "Version 0.1.2.3".ToCString()

Function TEST_GetVersion:Byte Ptr() Export "Win32"
	Return versionPtr
End Function

dll_test.bmx

SuperStrict

Framework Brl.StandardIO
Import pub.win32
Import brl.systemDefault 'Notify()


Local dllName:String = "dll.dll"
Local dllHandle:Byte Ptr = LoadLibraryW(dllName)
If Not dllHandle Then Notify dllName + " not loaded properly."; End
Print "loaded dll"

Global TEST_GetVersion$z() "Win32" = GetProcAddress(dllHandle, "TEST_GetVersion")


Print TEST_GetVersion()

"loaded dll" is never printed - nor is there a notification for a failed LoadLibraryW call.