B-Em: ROMs, Config and Linux Packaging

want to talk about MESS/model b/beebem/b-em/electrem/elkulator? do it here!
Post Reply
Coeus
Posts: 1084
Joined: Mon Jul 25, 2016 11:05 am
Contact:

B-Em: ROMs, Config and Linux Packaging

Post by Coeus » Sat Dec 09, 2017 5:10 pm

It has been mentioned before that it would be useful to have pre-built Linux packages for B-Em. There are two hurdles that I can see here:
  • Different Linux distributions with different package formats.
  • B-Em's expected directory structure.
.
The second of those is what I want to discuss here. Generally, Linux packages have an executable file which installs to a central place (for example /usr/bin/b-em) and then any other support files are installed to package-specific read-only (to non-root users) directories for example /usr/lib/b-em (if host CPU architecture specific) or /usr/share/b-em (if not).

This does not pose a problem for files you would be unlikely to want to change so we could have:
  • /usr/share/b-em/ddnoise
  • /usr/share/b-em/discs
  • /usr/share/b-em/icon
  • /usr/share/b-em/tapes
But what about ROMs? At the moment there is a sub-directory under roms for each model and the files in that directory are loaded as ROMs when B-Em starts with files starting with a number going into the specified slot and the rest then filling the remaining slots in descending order. But what if B-Em includes a ROM in the directory for a specific model and you would rather it wasn't loaded? It is generally not considered good practice to remove files installed as part of a package by your distribution's package manager. Or what if you want to re-arrange the order?

One option would be to have a user-specific ROMs directory that overrides the system one so for example, if starting a Model B and there is a /home/user/.config/b-em/roms/b directory the ROMs in that directory are loaded instead of the ones in /usr/share/b-em/roms/b. That would work if either the user setting up such a directory were to use symlinks for the distributed ROMs they did want to use, rather than just copying them, or if the version didn't need to match B-Em in any way but what of cases where the ROM needs to be matched to B-Em?

Another option is instead of using a directory for the ROMs to load for each model, use a section in the config file (b-em.cfg) instead which specifies what should be each slot. Where the file specified for a slot is a simple filename rather than a full pathname B-Em could then search in both a user-specific and in the central system directory. That means /home/user/.config/b-em/roms/b would then just contain a selection of ROM images you may or may not want to use for any particular model.

What do you reckon?

User avatar
ThomasAdam
Posts: 92
Joined: Tue Feb 07, 2017 9:35 am
Location: Southampton, England
Contact:

Re: B-Em: ROMs, Config and Linux Packaging

Post by ThomasAdam » Tue Dec 12, 2017 9:56 am

I don't think this warrants anything as complex. The work involved here is adding the relevant install targets for autoconf to use. That way, you don't have or need to worry about packaging as that can be Someone Else's Problem (i.e., the people whose job it is to package things up).

As for ROMs, do what all other Unix programs do. Honour INSTALL_PREFIX and have a directory structure for each emulated BBC type, under which different ROMs can then be placed. This can then be mirrored in XDG location in $HOME. See:

https://standards.freedesktop.org/based ... atest.html

-- Thomas Adam

Coeus
Posts: 1084
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: B-Em: ROMs, Config and Linux Packaging

Post by Coeus » Tue Dec 12, 2017 3:52 pm

ThomasAdam wrote:I don't think this warrants anything as complex. The work involved here is adding the relevant install targets for autoconf to use. That way, you don't have or need to worry about packaging as that can be Someone Else's Problem (i.e., the people whose job it is to package things up).

As for ROMs, do what all other Unix programs do. Honour INSTALL_PREFIX and have a directory structure for each emulated BBC type, under which different ROMs can then be placed. This can then be mirrored in XDG location in $HOME. See:

https://standards.freedesktop.org/based ... atest.html

-- Thomas Adam
Not sure whether to call this an interesting co-incidence or rotten timing but after concluding that no-one else seemed to have any views on this I went ahead with some changes just last night. I have just now pushed these to the sf/linux-pkg branch on the stardot github.

I am sure you mentioned that XDG document previously because I looked it up and, at the core of those changes, are a set of three functions that look for files in various places according to that specification. There is one to find a data file, i.e. which includes ROMs and sound samples (disk and tape noises) where the file is most likely to be packaged with B-Em, but could be overridden by the user providing an alternative version, and a pair, for "config" files where the file is user-specific and specifically allows a file to read from a version distributed with the package but written back to a user-specific directory. I then made every case of loading or saving a file use these functions rather a roll-your-own version of appending the filename to the directory the executable is in. I also included Windows implementations of these same functions that do, at least for now, just append the filename to the directory containing the executable.

On the question of ROM loading I did also implement a scheme whereby up to three ROMs are specified by the entry in the model table, i.e. OS, basic and DFS (or equivalent) and the rest loaded as specified by a config file but I would still be keen on the detail of how you think directory-based selection of ROMs would work with a mixture of packaged and user-sourced ROMs with the user choosing to override or not load a system shipped ROM.

User avatar
ThomasAdam
Posts: 92
Joined: Tue Feb 07, 2017 9:35 am
Location: Southampton, England
Contact:

Re: B-Em: ROMs, Config and Linux Packaging

Post by ThomasAdam » Tue Dec 12, 2017 4:20 pm

Hi Steve,
Coeus wrote:Not sure whether to call this an interesting co-incidence or rotten timing but after concluding that no-one else seemed to have any views on this I went ahead with some changes just last night. I have just now pushed these to the sf/linux-pkg branch on the stardot github.
OK, thanks. I've taken a quick look, and although some of the changes look OK, a lot of the helper functions you've added for file-path finding, etc., would naturally go away when you start looking at using autotools for the prefix directory locations for system-wide files, as well as XDG for user specified locations. XDG is the important standard to follow here since it's designed to allow for an arbitrary directory structure. I can see you've had a stab at it.

I'm not sure we need a different implementation for Windows/Linux in terms of find_dat_file() and friends -- POSIX still allows for "/" in file paths, even on Windows.

I think what's needed here is:
  • A common set of functions for traversing a known directory structure -- the paths are separate from the files themselves and hence one implementation can work for both Windows and Linux.
  • The directory structure should probably look something like this:

    Code: Select all

    ~/.config/b-em/
        roms/
            Master/
            ModelA/
            ModelB/
                ModelB.rom
                romA.rom
                romB.rom
    
    That is to say, the emulator ROM for the model is the same name (hence, loaded first), and then all other ROMs for that model.
  • Using autotools for the system-wide locations will involve additions to config.h so that these are accessible -- this will thankfully make the current set of file-location functions simpler.
The structure above would be the same for system-wide, too. Additionally, in terms of the user overriding things themselves -- because ROM-loading is dynamic in terms of what's available, I think it best to introduce a dialogue which indicates the ROMs which are loaded, and for that to be configurable. To do this, what I would recommend is getting b-em to copy into $XDG_DATA_HOME the ROM structure and always using that, regardless. Although it used to be the case that Unix programs shouldn't randomly install dot files for the user, that idea seems to have died out. Additionally, if we were to update ROMs, we can handle that via update hooks when we release new version of b-em.

-- Thomas

Coeus
Posts: 1084
Joined: Mon Jul 25, 2016 11:05 am
Contact:

Re: B-Em: ROMs, Config and Linux Packaging

Post by Coeus » Tue Dec 12, 2017 4:48 pm

ThomasAdam wrote:OK, thanks. I've taken a quick look, and although some of the changes look OK, a lot of the helper functions you've added for file-path finding, etc., would naturally go away when you start looking at using autotools for the prefix directory locations for system-wide files, as well as XDG for user specified locations. XDG is the important standard to follow here since it's designed to allow for an arbitrary directory structure. I can see you've had a stab at it.
So how do these helpers go away? I can imagine that autotools can be used to set the expected directory for system files, i.e. somewhere under the installation prefix, but what of the things under the user's home directory, i.e. $HOME/.config? Something has to expand the environment variable and construct the pathname from it. Autotools can't do that because it cannot forsee who the user running B-Em will be or what they home directory will be so it cannot construct that path statically.
ThomasAdam wrote:I'm not sure we need a different implementation for Windows/Linux in terms of find_dat_file() and friends -- POSIX still allows for "/" in file paths, even on Windows.
It is not so much a case that how a directory are filename are joined together needs to be different but that the set of directories to search needs to be different on Windows.
ThomasAdam wrote:I think what's needed here is:
  • A common set of functions for traversing a known directory structure -- the paths are separate from the files themselves and hence one implementation can work for both Windows and Linux.
  • The directory structure should probably look something like this:

    Code: Select all

    ~/.config/b-em/
        roms/
            Master/
            ModelA/
            ModelB/
                ModelB.rom
                romA.rom
                romB.rom
    
    That is to say, the emulator ROM for the model is the same name (hence, loaded first), and then all other ROMs for that model.
  • Using autotools for the system-wide locations will involve additions to config.h so that these are accessible -- this will thankfully make the current set of file-location functions simpler.
By emulator ROM did you mean OS ROM? That isn't that different from what we have prior to my most recent change, except that the OS ROMs are not in the sub-directories for the models they apply to, possibly because the same OS is used by several models, but then the same is true of basic and some other ROMS. Also, except for the fact the existing arrangement allows the ROMs to be named with a leading number to force them to load into specified slots which is sometimes needed if two or more ROMs offer the same service or command and you want to choose which one should get priority.
ThomasAdam wrote:The structure above would be the same for system-wide, too. Additionally, in terms of the user overriding things themselves -- because ROM-loading is dynamic in terms of what's available, I think it best to introduce a dialogue which indicates the ROMs which are loaded, and for that to be configurable.
There doesn't seem to be much in the way of widgets in Allegro 4. It does look like the building blocks may be there to build a dialogue that is not either a message box or a menu but it doesn't look trivial. It would be good to have a dialogue to manage ROMs, though. Is such a GUI sometime to postpone until Allegro 5 or could it be done now and ported forwards?
ThomasAdam wrote:To do this, what I would recommend is getting b-em to copy into $XDG_DATA_HOME the ROM structure and always using that, regardless. Although it used to be the case that Unix programs shouldn't randomly install dot files for the user, that idea seems to have died out. Additionally, if we were to update ROMs, we can handle that via update hooks when we release new version of b-em.
Except that the package installation hooks run as root for the system as a whole and probably shouldn't be searching all user's home directories to find things to update, though of course it is possible.

User avatar
richmond62
Posts: 223
Joined: Sun Apr 16, 2017 3:15 pm
Location: Bulgaria
Contact:

Re: B-Em: ROMs, Config and Linux Packaging

Post by richmond62 » Sun Dec 17, 2017 8:30 am

B-Em's expected directory structure.
I do 98% of my programming using LiveCode [ https://livecode.com/ ]

there is an Open Source version available: https://livecode.org/

LiveCode can deliver an entirely self-contained standalone for Linux.

I wonder if it might be possible to wrap B-Em inside a LiveCode standalone so that it
can be delivered to Linux as a monolithic application?

Post Reply