Works on one linux distro works on all?
Archives Forums/Linux Discussion/Works on one linux distro works on all?
| ||
| If I manage to get my game to compile and run (with sound) on one 32bit distro of Linux will other distro's 32 and 64 bit theoretically be able to run it too with sound? |
| ||
| As long as that distribution has those libraries required installed. Then the answer is yes. |
| ||
| thanks - are Linux users used to downloading libraries etc to get games and apps running? |
| ||
| Linux users are much less likely to want to install a 32-bit app on their 64-bit OS if they don't already have some 32-bit software installed already - since it requires the installing of a whole heap of supporting 32-bit libraries. The chances of a normal 64-bit Linux user already having 32-bit libraries installed is very low, since all the packages they will be downloading are 64-bit. |
| ||
| As Brucey has said a 64 bit distribution user would not likely have any 32 bit dependencies installed. But many Linux users expect your software to be packaged for use with their systems package manager. Building a package can be quite complex, especially when you throw in the many types of packaging systems there are. But creating a package will allow you to automate the installation of library dependencies. Thus saving the end user the task of manually installing them. There are many purists whom wouldn't want 32 bit stuff on their systems and would only tolerate 32 bit software if it was for a piece of hardware. I was messing around making a tool that created self extracting archives that could be customized to install the dependencies. http://www.blitzbasic.com/Community/post.php?topic=101454&post=1274926 |
| ||
| Most linux users trying my game liked the "unzip and play" approach. Same for the windows users. One "reviewer" of my game suggested to "sudo apt-get install steam" as it installed many 32bit libs. (source: http://kilobyte.bplaced.net/ubuntu-tvtower-spielen-rezension-und-installationshilfe/) Ubuntuusers.de suggested individual lib-name:386 packages https://wiki.ubuntuusers.de/Spiele/TVTower/ ... and others just mentioned "ldd TVTower" to find out what my game is missing ;-) Think your installer is of interest once a game reaches a final state and is getting placed to some popular spots. Once a distro wants your game in the repo, they will obviously need to build it on their own - which wasn't possible some months ago (when BMax had its closed source compiler). @dawlane What do you think of some script enabling building everything from source. -> you provide the source + the "script" and the script downloads and compiles BMax (if not available already), then compiles the sources and so on. Some kind of ./configure, ./make, ./autoconf, ./automake, ... bye Ron |
| ||
| Thanks all I assumed there would be lib concerns after the knight it was to get my Linux work with sound, I'll take a peek at your tool dawlane (ohh er) might save a headache. |
| ||
| What do you think of some script enabling building everything from source. Don't take offence Derron, but that would be a bad idea. Think of the overhead of band width, disk space and compile time. Not to mention all the things that can go wrong. You would be for ever answering support questions.-> you provide the source + the "script" and the script downloads and compiles BMax (if not available already), then compiles the sources and so on. Some kind of ./configure, ./make, ./autoconf, ./automake, ... If you need a bit of info on packages type 'anatomy of deb/rpm (or what ever) file' into google. It should come up with some interesting results. There's a lovely video just under an hour long on the subject for Debian packages. |
| ||
| Maybe a first step would be, to make "blitzmax" available for debian etc? This would then truncate the "compile my game" instructions to: - sudo apt-get install blitzmax - bmk makeapp mygame.bmx @disk space, compile time This is a one-time job: not available? Download and "make readyto use" Needed to fix an annoying bug in "mirrored" (reader for "Spiegel-Online"), an android app. They provided make files etc. ... it auto downloaded 1 or 1.5GB of stuff to compile everything. Of course it did no longer download things once it finished that and I recompiled until I squeezed the life out of the bug. (PS. no offence taken) @Sound Most often you will find people _not_ having pulseaudio installed in their distro, so they will run into trouble then. Or they do have "alsa" and no pulseaudio and as soon as they have another audio player running, your app wont be able to play sound then. Also make sure, that you use Bruceys FreeSound-variant, as it dynamically loads (or tries...) the libraries. If you do use the vanilla freesound-module your app will fail to start on linux computers without pulseaudio-libraries. These users wont install pulseaudio just for you (as you then have to setup your whole audio background, audio sinks etc.) bye Ron |
| ||
| Maybe a first step would be, to make "blitzmax" available for debian etc? Though this is doable. There are certain things that need to be taken into account.1) The official vanilla source BlitzMax is a 32 bit program. You have to over come the technicalities of getting the package to install the 32 bit dependencies it requires to build or run. This isn't easy as you think it would be on a 64 bit debian based system. Unbuntu 12.04 chokes and dies when it hits a dependency in the control file with :i386 even with the Multi-Arch: qualifier set correctly. The solution is to make two packages, one meta package to install the i386 runtime dependencies and the main package to install the development packages. 2) BlitzMax was written to be self contained. This will cause problems with file permissions. You could set the file permissions and groups to allow access, but as *nix systems are meant to be multi user in nature, any one user making a change will affect the whole application. BlitzMax would have to be altered to take this into account by using directories in the user own home directory. 3) Using debuild can corrupt up a number of files. The best thing is to put the whole BlitzMax directory into a tar.gz and unpack. It really loves fasm.... Note that I have been toying around with it most of this morning. |
| ||
| Note that I have been toying around with it most of this morning. And you seem to be still tinkering with it. @group permissions I completely blanked that out. So are you talking about "user modules" and "system wide modules" etc? If so, Blitzmax does not like symlinks (the brl-modules contain some "path recognition"-functions which do not check that perfectly). @64 bit hmm, the meta-package is a good idea. Dunno if it would be better to use BMX-NG then at all ? bye Ron |
| ||
| Actually Derron I've got it working with, but I wouldn't trust it yet on a production machine. I've not gone for the compile as you go route as it would take too much time to test. I'm still faffing with VMs for now. It still needs testing and improving with checks to make sure that it doesn't break the package system. The wrong execution of a command can bugger up a system good style. Then there is the question of gpg keys and adding bits to changes etc. As for permissions. The BlitzMax directory is owned by root, but I've done it so that a new blitzmax group is added and this group has rights to the BlitzMax directory. The sudo user who installed the package is automatically added to this group. Note no check yet for users under su. Any other user that needs access should be manually added to this group. As I remember the tmp and cfg directories are the only ones that need general access. Maybe a few alterations to redirect them to a directory created in the current logged in users home directory. Or break the taboo and set the permission on those directories to full for owner, group and others. As for modules, well that's the problem. Either it has to be a major rewrite or tricking the build system in some way. |
| ||
| If Blitzmax supported "two" modules directories - you could extend BMK/BCC to check the "linux-user"-module-directory too. @Permissions I would try to be as less intrusive as possible. While you are able to symlink BCC/BMK from /opt/... to be globally available, you first need to fix the Path-functions in the BMX-modules as they use the "real path", not the "path of the execution file" (eg the symlink to "BCC"). This gets important once you have to route directories. For normal "call bcc/bmk" this should be unimportant. This path-"inconvenience" also influences the modules and "module finding". At least I think I had trouble with this when using BMX-NG with everything being symlinked from (BCC, BMK, config, brl.mod, pub.mod ...) to individual git-repos. bye Ron |
| ||
| If Blitzmax supported "two" modules directories - you could extend BMK/BCC to check the "linux-user"-module-directory too. Well after a bit of digging around in the source and trial and error. I have managed so far to get Blitzmax to look and use a directory called blitzmax in the users home directory. And the tmp directory is redirected to /tmp/blitzmax would have to change things in the IDE for it to work correctly.It's now a case of "if you cannot find a module in the user directory, then go looking for it in the install directory". Which is a lot more tricky as both bcc and bmk have to be modified to some extent. As a side note as Blitzmax stands it wouldn't pass the stringent requirements needed to make it into a distributions repositories. |
   |