BMK (NG) - Source Available
BlitzMax Forums/BlitzMax NG/BMK (NG) - Source Available
| ||
| Hey Ho! The latest BMK NG source can be downloaded from the bmk github mirror. This version supports (over the official version) : * Cross-Compiling to Win32 on Linux and Mac platforms. * Cross-compiling to different architectures (like ARM on Linux), using my new bcc_ng. * Multi-threaded compilation of C/C++ files (when built with Threading enabled) * Universal Builds on Intel Mac. * More helpful error messages. * Version information : bmk -v * Usage information : bmk Remember to copy the latest core.bmk and make.bmk into the BlitzMax/bin dir. Requires : * BlitzMax 1.33+ I'm fairly happy with this at the moment. There may, of course, be problems that I've not yet come across, but I've been using it on Mac and Linux for building native, cross-compiled and Universal (mac-only!) builds. As usual, comments, suggestions and bug-reporting always welcome. :o) |
| ||
| Oh.. and the current CE-IDE has built-in support for all the new functionality of this BMK. Thanks Mark! And there's a version of the official IDE with support for them too, at my mingw page (source and Mac x86 binary available). |
| ||
| No problem Brucey (and yes, I spotted the bmk -v)...people can download CE IDE from the links in my sig... |
| ||
| Currently building all your modules with it Brucey ;-) Sometimes when I build your mod, there is precedence for others modules build sometimes later... No problem when it's about a fresh new install (I get warning and error, then just need to compile what's needed first) but there we have universal Mac binaries. Every modules are going from x86 to "x86 AND PPC". Would it be fair to assume that BCC WILL make a difference if a PPC module refer to a X86 modules (still not "converted"... do you still follow me ?). For example CEGUI is building before Freeimage while CEGUI need Freeimage first to be build. Is the relation from one module to another is C/C++ based or Blitz Object based ? In worst case : Do you think it's necessary to rebuild every Bah.mod a second time (just to be sure since I can't test PPC binaries). |
| ||
| For example CEGUI is building before Freeimage while CEGUI need Freeimage first to be build. You are right... that's not so great. I've uploaded a new version of the source which fixes this. Interestingly, it appears that BMK, when told to build a single module, will actually process ALL modules to see if the name matches... which isn't very efficient. So I've tweaked that part of the build process, and it will only look at the specified module if you give it one (plus its dependency tree of course). I've tested it out on a few variations, and it seems to be okay. Every modules are going from x86 to "x86 AND PPC". It builds both PPC and x86 versions of the modules. It will also build a PPC and x86 version of your finall Application binary... after which it will merge those two together to form a single Universal binary. Note, that if you incbin data, it essentially will be incbin'd twice, since you get TWO compiled app binaries. (something to think about if you incbin a lot of stuff) You may rather wish to consider storing your data in the Resources folder inside the application bundle. |
| ||
I'm getting a load of errors trying to compile and run this:
SuperStrict
Framework brl.standardio
Print("Hello.. World?")I get this error on the threaded and non-threaded build of bmk_ng (the application is being compiled in non-threaded mode): http://pastebin.com/m78628982 EDIT: I also recompiled the modules for each test (and they worked lovingly, as expected, on the original bmk): 'bmk makemods -a'. |
| ||
| Ok so I needed to rebuild modules twice yesterday and the universal binaries effectively well merged the two version :) You are right about the incbin that double size my executable (from 12Mo to 24Mo). Not very problematic but I wonder if there is something like UPX for Universal binaries ? That would probably fix the problem since "by design" I didn't include my assets in a resources folder and doing so would require a bit amount of work which I need to consider before release 3 versions (Windows, Linux, Mac) of the title. I only need to finish my next alpha-demo version before testing this widely. As always : Thanks for this huge tweak :D |
| ||
| I'm getting a load of errors You can tell I'm having lots of fun with this.. eh? :-p Updated yet again. Ho Hum. |
| ||
| It has already been proposed in the Mac forum but it's probably a better place to ask you this : Since I don't know about UPX for mac or anything : Would it be possible to have an option to separate PPC and Intel binaries ? Would save a bit of bandwith and maybe RAM (depending on how Mac load that universal binaries) since I will probably distribute this as a DMG file. |
| ||
| Updated with a couple of minor fixes (version 2.03). * Improved custom options support for Universal builds. * Fixed import ordering. I've also changed the setting of options. Previously one would use : addccopt optimization -O3 which didn't really make much sense for a single-value option. So, I've changed it to: setccopt optimization -O3 instead. For those which can have multiple settings - like a list of include folders - you can still use "add". |
| ||
| Hey Brucey, Had another play trying to get your BMK NG working with my install this afternoon and have managed to get it working (think you were right, I was missing some .bmk files). Quick question: have you recompiled your BMK NG as a threaded build using the latest dev version of Max? It compiles OK for me, but when I try to build modules or anything with it, I just get "cannot build" errors at blitz_app.c. Non-threaded build of BMK NG appears to work perfectly. |
| ||
| have you recompiled your BMK NG as a threaded build using the latest dev version of Max? No. Hold on. I'll give it a go. (once I've done a -h build of the modules :-p ) |
| ||
Heh... crap.
If FileType( BlitzMaxpath()+"/mod/brl.mod/blitz.mod/bdwgc" )=FILETYPE_DIR
threadedenable=CreateMenu("Threaded Build",MENUTHREADEDENABLED,buildoptions)
EndIf
That's not helpful :-p ... need to chuck in an empty folder to make the menu option appear for now ;-) |
| ||
| Hehe, I wondered about the missing option, but I got around that by running a threaded Build Modules from the official MaxIDE :P but it looks like the process is failing itself. To clarify, it chokes if I try to build modules without threading, if I'm using the threaded BMK NG. P.S. Can you check-out the latest version of MaxIDE v1.34 RC1b I uploaded to the dev team thread and let me know whether it fixes that link copying problem you reported? Universal build, naturally... ;-) |
| ||
| Seems to be okay here. Just running a "./bmk makemods -a qt" (on Mac) Version number is : > ./bmk -v bmk 2.03 mt-macos-x86 If you wait a while I'll get a win32 mt build going. |
| ||
Oooh... that's interesting :-p> ./bmk makemods -h -l win32 Compiling:blitz_app.c Compiling:blitz_types.c Build Error: failed to compile (137) /Applications/BlitzMax/mod/brl.mod/blitz.mod/blitz_app.c I'll look into it. It simply forks off the process and builds them in parallel... which has worked fine til now. Fun fun. |
| ||
| Build Error: failed to compile (137) /Applications/BlitzMax/mod/brl.mod/blitz.mod/blitz_app.c Bingo... :-( I have absolutely no idea about threading, but might it have something to do with whatever that recursive mutex behaviour was that changed for Mac OS/Linux in Max 1.34? |
| ||
| Righty... tracked down the "real" returned error, which is EINTR - "Interrupted system call". So, something's not happy when the process is forked. Looks like it just bombs out immediately. Which it didn't used to do... |
| ||
| Okay... the MT build is broken currently with the new GC. It'll only work with 1.33.... Ho hum. Threading is fun ;-) |
| ||
| Threading is fun ;-) Depends on the point of view I'd say... ;-) |
| ||
| Righty. It's working again, with the still to be released 1.34 :-) Although I'm going to bump this up a version because there's a couple of small changes which make reporting threading errors a bit clearer. |
| ||
| Hi Would it be possible to dispose of binaries version of this for the latest 1.34 RC7 ? Because when upgrading to newer version of Blitzmax generally we remove the last one. Rebuild twice every mods is quite annoying. Wouldn't it be nice to have this part of the official BMK ? Like the tweaked BMK ? After all it's another tweak to introduce parameters (like setccopt optimization -O3) in order to speed-up things no ? Mark... if you read this ;) Thanks |
| ||
| Wouldn't it be nice to have this part of the official BMK ? Like the tweaked BMK ? The tweaked BMK additions were a more generally useful set of improvements. I think the current NG changes are more specific to certain usage, and therefore not very useful to most. I personally use the Mac Universal and Win32 cross-compile options, and post-build scripts all the time (in fact all the qtmax examples come with post-build scripts because I'm too lazy to copy dlls these days) - but then I'm not normal... so :-p So you want me to provide pre-compiled BMK NG exes? |
| ||
| So you want me to provide pre-compiled BMK NG exes? Hummm ? Maybe :D ? Using BMK NG is probably something you do a lot. In my case and probably like many others I simply think about it once every new version of BlitzMax where I need to remember how it works. I remember having small performance boost while using your Win32 BMK and since Max2D rendering is greedy it's always good to take. But I can stick with the current RC7 until then of course :) (ohm... I wish Max2d were faster) |
| ||
| I compiled bmk.bmx in the folder, pasted the new EXE into ./bin and got this error message when i tried to run a blitzmax program Unrecognized app source file extension:bmx |
| ||
| Did you follow all the instructions in the readme.txt file? :-) Specifically, in the "Deploying BMK" section, it says this : The bmk executable, core.bmk and make.bmk, should be deployed in the BlitzMax/bin folder. If you feel I'm missing some more detailed instructions, let me know and I can beef it up a bit. |
| ||
| oh yeah I didnt RTFM sorry |
| ||
| I think you still have some thread-related problems. I see it freezing every once in a while (like a ~10% chance) when I run Rebuild Modules, always when compiling some c file. I have a build with threading enabled and BlitzMax 1.36 on Linux. |
| ||
| I have been getting this for a few days Building Modules Unrecognized Import file type: src/google/protobuf/stubs/common.cc Process complete I have just rebuilt the bmk.exe as per your website page. I followed some other threads and i believe i am all up to date. Any ideas? Win7,BM1.38,maxide1.37 |
| ||
| Check you also have the latest .bmk files in the bin folder, especially make.bmk (which has the list of supported file extensions) :-) |
| ||
| i downloaded your bmk2.zip file on the 16th Jan this year and built the bmk.bmx from that. all the bmx files from your zip file were last modified in 2007? |
| ||
| The one at the top of the page.. has a newer release date than Jan 16th. You should try that one :-) |
| ||
| got it. Thanks |
| ||
| Updated with a fix for PPC Universal linking... (Thanks Google!) |
| ||
| Updated with a fix for including your own custom bmk files. (it wasn't locating them in the current build folder) |
| ||
| building the newest source through MaxIDE-CE with multithreading enabled is just generating bmk, not bmk.mt. Is this just the file not being named right or is it actually not building it multithreaded? |
| ||
| It's nothing to do with my source... If you have multi-threading enabled, I'd expect to see the .mt extension on the file you create. So, either : * the CE IDE isn't applying it? * your bmk isn't applying it? * it's compiled somewhere else? * or hasn't built it at all (but then I'd expect to see an error message somewhere!) |
| ||
| CE is doing multithread with my project so I'm fairly certain it can... though maybe it doesn't with a console app? I am using the last released source, which the reason for the update was not running custom bmk's, does the mt extension come from a bmk? I'm getting a fresh bmk file in the build directory, it just doesn't have the .mt extension, and it works when I move it into bin (careful to preserve my previous version of course)... so it works I just don't know if it's multithreading or not... will get a clean 1.39 with official ide and try again with that which will probably work. |
| ||
Will putting this in rem:t=WriteStream( exeDir+"/Contents/Info.plist" ) If Not t Throw "Unable to create Info.plist" t.WriteLine "<?xml version=~q1.0~q encoding=~qUTF-8~q?>" t.WriteLine "<!DOCTYPE plist PUBLIC ~q-//Apple Computer//DTD PLIST 1.0//EN~q ~qhttp://www.apple.com/DTDs/PropertyList-1.0.dtd~q>" t.WriteLine "<plist version=~q1.0~q>" t.WriteLine "<dict>" t.WriteLine "~t<key>CFBundleExecutable</key>" t.WriteLine "~t<string>"+appId+"</string>" t.WriteLine "~t<key>CFBundleIconFile</key>" t.WriteLine "~t<string>"+appId+"</string>" t.WriteLine "~t<key>CFBundlePackageType</key>" t.WriteLine "~t<string>APPL</string>" t.WriteLine "</dict>" t.WriteLine "</plist>" t.Close t=WriteStream( exeDir+"/Contents/Resources/"+appId+".icns" ) If Not t Throw "Unable to create icons" Local in:TStream=ReadStream( "incbin::macos.icns" ) CopyStream in,t in.Close t.Close Stop the compiler from putting the Blitz Logo into the app for an icon. I always hated the Mac Compiler for doing that, as I'd rather use my own icons ;) |
| ||
I use a post.bmk file to handle the icons.# MacOS post build script # # @define doPostInstall # only interested for Mac platform if bmk.Platform() == "macos" then #copy icons sys.CopyFile(%buildpath% .. "/Bin/icon.icns", %exepath% .. "/../Resources/" .. %outfile% .. ".icns") #copy info.plist sys.CopyFile(%buildpath% .. "/Bin/info.plist", %exepath% .. "/../info.plist") end @end # run the post install doPostInstall it also copies a modified info.plist for version info and the other whatsits that you might want (document associations etc...) it's a bit cumbersome to set up for each project, but once you've got it in place, combined with CE and you can build everything ready to share with testers in a minute for universal mac and windows... saves CRAZY time. |
| ||
| Hi Brucey I was wondering. Does bmk.exe change when updating BlitzMax ? I have just installed the 1.41 and was wondering if BMK (NG) was still "compatible" with the current version of BlitzMax. I always rebuild from this 2.09 version of BMK (NG) (released 30 Apr 2010). Thanks ! |
| ||
| I was wondering about this compatibility issue, too... |
| ||
| The main bmk doesn't change very often, so you should be okay. bmk just calls the different command-line programs in the correct order - bcc, gcc, g++, ar, ld, etc. It's like SCons, or Make, but a BlitzMaxified version. |
| ||
| Updated for the latest release.... |
| ||
| Updated for the 2.11 release, which changes the Win32 linker to use g++ instead of ld... |
| ||
| Hi Brucey, Just got around to trying the 2_11 release , but it doesn't appear to work on my computer. Everything I compile (even just the "print" command) gives me the following error message on windows: Linking:untitled3.exe ld: cannot find crtbegin.o: No such file or directory ld: cannot find -lstdc++ ld: cannot find -lgcc ld: cannot find -lgcc ld: cannot find crtend.o: No such file or directory Build Error: Failed to link C:/Code/BlitzMax/tmp/untitled3.exe for what it's worth, both of these exist on my system: BlitzMax\lib\crtbegin.o C:\MinGW\lib\gcc\mingw32\4.5.1\crtbegin.o 2.11 -does- work if I use the custom.bmk option to tell it to link with LD instead. Does the g++ linking require any additional environment variables to locate the files or something? |
| ||
| Thanks... it's working here for some reason. (and should do, for everyone else too!) |
| ||
| Was that a GUI or console build? |
| ||
| Here's my output from building a file from the tmp dir (just a basic SuperStrict with a Print "Hello") The key is the last bit, which now uses g++ to do the linking. g++ should take care of all those libraries and crt file parts... that need to be manually configured when using ld. |
| ||
| Was that a GUI or console build? It was just hitting f5 (build and run) on anything in the IDE. anyway, after removing the GCC_EXEC_PREFIX=C:\MinGW environment variable, things -appear- to compile OK now. hopefully that'll take care of it. Weird... :-? |
| ||
| Oh... another issue with GCC_EXEC_PREFIX ! I'm not even sure what's going on any more.... :-( Ho hum... |
| ||
| I'll bump this up to 2.12 with the latest Lion tweaks from the official version later today. Scales so nicely with my new Mac Mini i7 processor, seeing 4 processors (dual core with 2 hardware threads per core), and rebuilding all modules at a crazy rate! Yummy multi-process goodness all round :) |
| ||
Oh that's FUN! I love watching Activity Monitor strain :0) |
| ||
| Cool :-) |
| ||
| Hi, does anyone have the sourcecode and could reupload the zip-file? Seems like brucey.net isn't about to get back online :( |
| ||
| It's up. It seems it was down yesterday for some reason... |
| ||
| still not working here Brucey. Cheers Charlie |
| ||
| I wonder if they had DNS problems, as my mail was off too yesterday - couldn't find the site... But anyway, I'm now hosting the source on googlecode. I'll put a proper release up tomorrow (9th), but for now : http://code.google.com/p/bmkng/ |
| ||
| Hey thanks for the code google link. Seems like your provider has some major trouble because I tried it over the past 2 weeks. I only could load your Website once (09.09.2011, after your response). Btw. I cant connect at the moment. (11. Sep 2011 10:00 from Germany) |
| ||
| I'm not 100% sure on this, so correct me if I'm crazy. I had some issues with some crazy memory things. Eventually made them go away by futzing around with modules and bmk under lion (see my lengthy rambling thread in programming for details). One thing I had to do was rebuild the official bmk under lion replacing "-4.2" with " -4.2" in 2 places. without the space g++ command breaks since there's no space for the arg... I assumed the lion compatible BMK NG would have the same issue. I haven't tried it under lion but I have searched for and replaced 2 instances of "-4.2" with " -4.2". One was in bmk_util.bmx as the official ones were, one was in make.bmk, which isn't surprising since BMK NG obviously uses bmk files to work it's voodoo magic that I can't live without... Again, I haven't gone back to lion to vet this under lion, but I suspect it will work where it didn't before... hopefully this is helpful. |
| ||
| Hi Hi Captain ! I'm 100% sure I did not change a thing to my BlitzMax installation since a year, but today when I try to build any samples I always run into this: C:/BlitzMax/mod/pub.mod/libpng.mod/libpng.release.win32.x86.a(png.c.release.win32.x86.o)(.text+0x7b8):png.c: undefined reference to `png_mmx_support' C:/BlitzMax/mod/pub.mod/libpng.mod/libpng.release.win32.x86.a(pngread.c.release.win32.x86.o)(.text+0xa1d):pngread.c: undefined reference to `png_combine_row' C:/BlitzMax/mod/pub.mod/libpng.mod/libpng.release.win32.x86.a(pngread.c.release.win32.x86.o)(.text+0xc04):pngread.c: undefined reference to `png_read_filter_row' C:/BlitzMax/mod/pub.mod/libpng.mod/libpng.release.win32.x86.a(pngread.c.release.win32.x86.o)(.text+0xc7d):pngread.c: undefined reference to `png_do_read_interlace' C:/BlitzMax/mod/pub.mod/libpng.mod/libpng.release.win32.x86.a(pngread.c.release.win32.x86.o)(.text+0xc97):pngread.c: undefined reference to `png_combine_row' C:/BlitzMax/mod/pub.mod/libpng.mod/libpng.release.win32.x86.a(pngread.c.release.win32.x86.o)(.text+0xcbf):pngread.c: undefined reference to `png_combine_row' C:/BlitzMax/mod/pub.mod/libpng.mod/libpng.release.win32.x86.a(pngread.c.release.win32.x86.o)(.text+0xcd2):pngread.c: undefined reference to `png_combine_row' I already saw someone having those references error and since it was with a BMK modification, I try to restore the BMK.exe (hopefully I always keep a backup just in case). Rebuilding "brl.libpng" only with the original BMK fix the problem. It is not impossible that I stopped checking the BlitzMax samples as soon as I started working on my game 2 years ago, so probably this problem always existed (but curiously not with my game through I use a lot of PNG). But today I want to try TimelineFX as a particles engine replacement and those errors popup again. Is there anything I can do about this ? Not that I cannot do without a BMK(NG) version of the "libpng" module but it makes things complicated. By the way Brucey, I sent you a few emails at your addresses while I was abroad over the year but the Mailer Daemon return most of them. You may have a problem with @brucey.net ? |
| ||
| It appears that the latest bmk_ng no longer works with Blitzmax 1.44 / GCC 4.6.1 -- when doing a 'makemods' it doesnt' show anything, and when doing a 'makemods -a' all it shows it a bunch of lines that say 'archiving <modulename>', nothing else. Any idea? |
| ||
| Bump. |
| ||
| Sorry. I've been away for a few weeks. Need to sort out a new host for my website and email too, it seems... ho hum. I've committed some fixes to the ng source. Will do a full release later. |
| ||
| I've committed some fixes to the ng source. Will do a full release later. I did an svn sync just now, but still the same problem -- all it says is "archiving", no actual (re)compilation is apparent. when I do a -v it tells me "bmk 2.14 mt-win32-x86 / gcc 40601 (cpu x4)" |
| ||
| Strange... I did this : * Moved old Mingw and BlitzMax. * Installed new Mingw and BlitzMax * Built bmk_ng on new BlitzMax. * Replaced bmk.exe with mine, along with the relevant .bmk files. * Rebuilt all modules. * Moved bah.mod from the old BlitzMax to the new one. * Rebuilt specific modules for testing. All worked as expected. I even put back the old mingw and BlitzMax to test that the new bmk_ng still worked on the older version. |
| ||
| I think I found the problem -- I still had a custom.bmk in the bin folder as well from the previous install, and it apparently threw a wrench into the mix in 1.44. Removing custom.bmk, and it appears to work again. Thanks for looking into it, though! (As a sidenote: See my other message, bah.chipmunk and bah.magick do error out on compilation under windows with the latest blitzmax, both with bmk_ng and the official bmk) |
| ||
| Need to sort out a new host for my website and email too, it seems... ho hum. Sh*t happens ^^ I'm finally a Mac OS X (lion) users :D At last, I can build release for Mac in seconds (rather than 6 hours on a virtual Machine). The learning curve is pretty step! But I'm sure I will get used to it (except switching from keyboards to keyboards perhaps). I get my first mac the day Steve jobs passed away. What a curious coincidence... Glad to see that BMK_NG is still supported :) I'm currently considering PowerPC users. I read a few notes saying there is still a large group users even if Apple drop PPC support on Lion. |
| ||
| *Herm... I already drop the idea :-D See http://blitzmax.com/Community/posts.php?topic=95999 |
| ||
| I have two little feature requests that would ease development of modules in C: 1. BlitzMax compiler flag Something along the lines of predefining __blitzmax (like __cplusplus). Of course this can easily be achieved by using ModuleInfo "CC_OPTS: -D__blitzmax" but that is not a very clean way I think. 2. Check for "blitz_classes.i" in all modules Right now the blitz_classes.i file is only used in brl.blitz, but it is really great for writing BlitzMax Objects in C manually. Other than that: Great stuff : ) |
| ||
| On my Mac tabs are not displaying meaning all code is very close to the left edge. They're not even displaying as wide as space characters. Any ideas? |
| ||
| I think this is a problem with the MaxIDE that has nothing to do with an altered bmk. The simplest solution that works on my machine ( Mac OS X 10.6 ) is to save and reopen the file. After that all tabs should be displayed correctly, although I have no idea what causes the problem in the first place. |
| ||
| I've seen the close and reopen issue, but even that doesn't help with MaxIDE CE. Sorry just realised this is the wrong thread... Last edited 2011 |
| ||
| any chance to get this working with xcode 4.5.2 / 10.8.2 and blitzmax 1.4.9 ? i'am trying to compile bah.freeimage (i need this for the opencv stuff in ofx.mod but i'm out of luck in the moment...) |
| ||
| to answer my own question: this is because of the gcc and 10.6.sdk dependence of bmk (<1.4.9), on which bmk-ng is based. to ask a new question: is there a workaround or fix for this? |
| ||
| I've updated the download of bmk_ng which reflects the recent changes to the official bmk. I haven't tested it on 10.8. |
| ||
| Nice move :) Blitzmax is pretty stable and basically done. Certainly the best moment to experiment and improve every bits of it. Unfortunately people decide it's dead and that we should focus on something else... Oh well... |
| ||
| Mostly it needs 64-bit support, less assm and more portability. (ARM/ more platforms) |
| ||
a small mod to bmk_util.bmx (Type TModOpt):
Function setPath:String(value:String, path:String)
value=value.Replace("%PWD%",path)
Repeat
Local a:Int,i:Int
a=value.find("%")
If a=-1 Then Exit
i=value.find("%",a+1)
If i=-1 Then Exit
value=value[..a]+getenv_(value[a+1..i])+value[i+1..]
Forever
Return value
End Function
example of use: Moduleinfo "CC_OPTS: -I%MINGW%/include" |
| ||
| Do I need the updated bmk version in order to run the other module updates properly? Is a windows executable hosted somewhere? |
| ||
| Is a windows executable hosted somewhere? It doesn't have any "third party" requirements, and so can be compiled with a standard BlitzMax distro. The newest version in SVN adds some functionality to ease cross-compiling on Linux to other processors (e.g. ARM, x64, etc.) |
| ||
| Brucey, colour me excited! I aim to try newest version out this weekend. |
| ||
| @ARM I assume this wont work with "vanilla Blitzmax". bye Ron |
| ||
| @x64 Nor this. |
| ||
| Wait, did I miss something? BlitzMax can be compiled to x64 and ARM? But on Linux only, or am I misunderstanding? |
| ||
| I don't know of any ARM-based Windows systems? |
| ||
| ... |
| ||
| I don't know of any ARM-based Windows systems? Consider yourself blessed. A random collection of goats could create a better OS than either WindowsCE or <shudder> WindowsRT. |
| ||
| I don't know of any ARM-based Windows systems? Windows RT. It ook all the bad parts of Windows 8 and kept them (metro) and dropped the good parts (backwards compatibility with x86, 'legacy' windows applications, the desktop, etc.) Needless to say, they've been an abysmal failure in the market. |
| ||
| WindowsRT Ah, I see... does Monkey support builds for RT? |
| ||
| Cross-compiling on OS X to Linux-ARM target is now working rather splendidly ;-) |
| ||
| Hello Brucey. I could get BlitzMax NG on the run on Mac now (El Capitan). I've read the documentation on how to build Windows apps in it, and that is pretty clear to me and I will try to sort that out in a few days. I am however also interested in outputting to Android and Web (from Mac), and I did not find any documentation about those two platforms. It is my guess I need the Android SDK to output to Android (any specific version required?), and what should I do to get outputting to web (I guess that would be HTML5) working? (EDIT: I would normally put this in a GitHub issue, but for some reason GitHub refuses to let me in on this PC. In Mac BlitzNG now works for me, and when compiling Mac programs no trouble at all. In Windows, I first tried this on a VM, and now in my office where I have a "real" windows PC, I can get all stuff to compile, however MaxIDE for NG causes an EXCEPTION_ACCESS_VIOLATION during loading. Bmk and bcc, do nothing at all. When I try to start them I just get the dospromt again, like I never gave any request at all. When I try to use these programs however to compile fo Windows from Mac, the programs do run (and "wine bcc.exe -v" does retun the version number from Mac) Trying to build the modules will however result to a compile error in one of the .c files (I need my mac which I don't have here to tell you which one specifically and the exact error). I wonder what is going on. BTW. The VM I used uses Windows 7. Here in at my work's PC I have Win10. |
   |