BlitzMax roadmap
BlitzMax Forums/BlitzMax Programming/BlitzMax roadmap
| ||
| As part of a long term support proposal I would like to discuss any issues that could impact any future releases of BlitzMax. BlitzMax For Mac New installer is awesome but until it is signed still requires a control click open to kick things off. Solutions include an AppStore version or a MaxIDE release that can "build from source". BlitzMax For Windows Update MinGW binaries and update "officially endorsed" distribution. BlitzMax for Linux Fix stability issues with latest GCC tool chains. Include multilib and friends install script for "official debian 64 support". |
| ||
| The problem I see with 32-bit apps on 64-bit Linux is that even if you manage to get your dev environment set up and can successfully build stuff on it, you are then expecting Joe User to install 32-bit runtime just so that he can run your app - which may well be beyond the capabilities of said users. I believe the likes of Humble Bundle are only accepting 64-bit Linux apps, these days - perhaps for the reasons I mention above. |
| ||
| If you plan to create these distributions/packages you might need to have access to the git repo...or create an "official fork". Bye Ron |
| ||
| Fix stability issues with latest GCC tool chains What stability issues? For Linux MaxGUI, you may also be interested in https://github.com/maxmods/gtk.mod ... which is a Gtk+3 port of the BaH Gtk modules. I've only tested it as much as using it for my copy of MaxIDE, but it's been stable so far - although I'm only working in 64-bit on Linux. |
| ||
| I ran face first into this issue lastnight and am determined to sort out a fix. Brucey, I would very very much like to retire fltk so will be taking another look at gtk.mod. |
| ||
| ... and determined to sort out a fix. I posted a link for a fix at the end there that I implemented in my "updated brl/pub modules" repo on github. I've never offered any pull requests on the official repo as it's never seemed to receive much in the way of love - until perhaps now? |
| ||
| The problem I see with 32-bit apps on 64-bit Linux is that even if you manage to get your dev environment set up and can successfully build stuff on it, you are then expecting Joe User to install 32-bit runtime just so that he can run your app - which may well be beyond the capabilities of said users. When it comes to distributing your own software you would write your own dependency install script or distribute it as a package suitable for the end users own system. BlitzMax as it stands, is not suitable to be distributed as a system package without a few major alterations such as each user would have to have their own copy of the samples and modules directory in their home folder. Fix stability issues with latest GCC tool chains You will find out that the segfault is only with the current versions of bmk & bcc and then only happens when you compile and run a release binary. I did actually figure out a workaround by using the git version to first build bmk and bcc separately as debug versions so that you didn't end up building a new bmk/bcc with the previous bmk/bcc, before using the two new binaries to to rebuild all the modules. If anything, it looked like the supplied binaries just needed rebuilding.http://www.blitzbasic.com/Community/posts.php?topic=106988 One of the most annoying issues has to be the restoration of the displays after a full screen BlitzMax application has finished. |
| ||
| @ displays Multi monitor setups would be less problematic when using Bruceys sdl.mod at least it should care more. Think we had this in another thread already (with xandr and so on). Maxmods-brl/pub modules also contain fixes for appsuspended on linux (not working with vanilla). Dunno if this is helpful for tackling multimonitor fullscreen and alt-tab (did not play fullscreen for now..just got the issue reported long time ago) Bye Ron |
| ||
| i'm not quite sure, but I believe that mac store downloads must be 64bit and not 32bit. so vanilla blitzmax wouldn't be passed |
| ||
| ... I believe that mac store downloads must be 64bit ... There's nothing I can find that specifies that requirement, but it's certainly worth considering in this day and age. |
| ||
| @MacOS Appstore: https://developer.apple.com/app-store/review/guidelines/2016-06-13/mac/ |
| ||
| Couldn't you fake 64bit for them? 64bit wrapper calling 32bit binaries ? bye Ron |
| ||
| If anyone is interested here is the git version with a few Linux patches and pre-built bmk/bcc binaries built against GCC 5.4.0 (20160609), so they should work on Ubuntu 16.04. You will have to have the necessary dependencies installed and enter the _src/linux_x86 and run the install.bat. I will keep the link on for a few days. Couldn't you fake 64bit for them? I think that Apple would reject them.It would have been nice if Apple clarified item number 24 in section 2: Functionality. As far as I am aware the Carbon interface is depreciated, but still shipped. |
| ||
| (if you do not want to expose your family name to us, you might mirror the download to something not exposing your pre+familyname). What Linux patches did you include - beside the ones the "dependency+patch script" already does? bye ron |
| ||
| I have no issue (hopefully) using NG for the MaxIDE Appstore version. The objective would be that given a modern XCode environment it can act as installer / turnkey that builds either BlitzMax tool chain from source using the developers own debug key (free in xcode I think). I pay apple developer tax so have no problems signing such a version. |
| ||
| @Derron: What's it showing? All hidden files should be removed |
| ||
| on the dropbox site (of your link) the right info panel contained your full name (Jason XXX). As your website (dawlanesoftware) is no longer reachable I was not sure if that is intended. Did not want to create much fuzz about it. bye Ron |
| ||
| @Derron: Try it now. Dropbox should only show my name and allow comments. If you are logged into dropbox I haven't got a clue what it shows. @patches: All I have done is the basic stuff that you would find in the How to install. |
| ||
| Ok your nickname is now presented. Sorry for thread-derailing. bye Ron |
| ||
| The problem I see with 32-bit apps on 64-bit Linux is that even if you manage to get your dev environment set up and can successfully build stuff on it, you are then expecting Joe User to install 32-bit runtime just so that he can run your app - which may well be beyond the capabilities of said users. The 32-bit limitation is a serious issue. I use a script that installs the necessary 32-bit libs at launch, but I am presently stuck developing on Ubuntu 12.04 due to big changes in the way they store 32-bit libraries. I also have encountered difficulties installing certain 32-bit dev packages, and as a result my software is lagging behind on some features on Linux. These kinds of problems are only going to get worse with time. I'd be happy to move completely over to 64-bit exclusively and drop 32-bit support altogether. |
| ||
| Windows has Windows 32 on Windows 64 or Wow64 so you can run 32 bit programs on 64 bit OS. I wonder if something like that could be done for linux. Just one package installed, and your system will (mostly) be able to run anything a 32 bit install would run. A Lol64 :D |
| ||
| My own priority is the win32 BCC, BMK, MaxGUI stack. I personally think MinGW smells and that the only medium size change I would like to attempt with BlitzMax Vanilla is visual studio tool chain support (which is how I was running bmk at my BRL job before release). |
   |