multi-user support

[ebenblues]

Ebenblues has made a lot of progress on the gui/nogui merge, and as part of this work he is adding the functionality which will allow Mupen64 to be installed in a normal way with binary distributions.

Just wanted to start a new thread to discuss what multi-user support entails. My understanding is we want to add support for multi-user config (~/.mupen64 directory) and support for a 'make install' target in the Makefile.

Regarding the ~/.mupen64. Here are my initial thoughts:

1. When mupen64 first starts, if a dir called .mupen64 exists in the user's home directory, and Userdir=0 is not set in the config file, set the working directory to that dir and print an info message informing the user of this (will appear in the statusbar in gui or console in NOGUI_ONLY version).
2. If ~/.mupen64 doesn't exist and Userdir=0 is not set in the config file, ask the user if they want to create it. in GUI mode, this will be a confirmation dialog box that pops up. The dialog will have a "don't ask me again" checkbox which, if checked and the user selects no, will set "Userdir=0" in the config file.
3. If the user chooses yes, create the .mupen64 dir and copy all default config files from the install dir (see below) to ~/.mupen64. symlink plugins, language files, and icons from install dir.

As for the 'make install' option, honestly, my first thought is why aren't we using autoconf? I could picture all of the options we're passing to make today as options to ./configure, then make && make install would install everything. This would make it very distro-friendly.

Let me know what you think.

 

[Richard42]

Ebenblues,

I agree with your proposal for handling the multi-user configuration, except the last part of your 3rd point. I think we should completely separate the binaries and fixed data (including executables, icons, language, plugins) from the user-specific data (eeprom dumps, system snapshots, screenshots, config files, ini files). I also recommend removing the symbolic link mechanism because that is a hack. It's inflexible and provides no benefit. Either the fixed data should be required to be in subfolders of the mupen64 directory with the executable (this is what I would recommend), or you can build a mechanism to control the location of the fixed data.

The lack of autotools, et al, is as usual a historical one. No-one has ever taken the time to set this project up with autotools. A couple of years ago I read through a bunch of documentation describing the required steps for setting up a project with autotools and how it all works, and decided that it was way too complicated for my needs. OTOH, I have a colleague at work who has set up several projects with autotools and he has told me that it's not terribly hard. I think autotools is great if you want to support a very diverse range of systems (linux, aix, bsd, cygwin, beos, etc), which is why they're used by all of the GNU projects. But Mupen64-amd64 is being developed and tested only against i686 and x86_64 linux systems, so the range of variations which need to be handled by the build system is not very broad, and the bulk of autotools is unnecessary. If someone really wanted to set up Mupen64-amd64 with autotools and could explain the benefits for adding the complexity to the build system, I would merge it into the SVN tree, but it's not a very high priority for me.

Another build change that I have been contemplating is unifying the tree by moving the RiceVideoLinux and Glide64 plugins into the main mupen64 build, and maybe removing the broken software gfx plugin. Perhaps this should be synchronized with the rollout of a better name for the fused project than mupen64-amd64. Thoughts?

 

[ebenblues]

I agree with your proposal for handling the multi-user configuration, except the last part of your 3rd point. I think we should completely separate the binaries and fixed data (including executables, icons, language, plugins) from the user-specific data (eeprom dumps, system snapshots, screenshots, config files, ini files). I also recommend removing the symbolic link mechanism because that is a hack. It's inflexible and provides no benefit. Either the fixed data should be required to be in subfolders of the mupen64 directory with the executable (this is what I would recommend), or you can build a mechanism to control the location of the fixed data.

I'm ok w/ keeping that data separate. The only advantage I can think of that a plugins dir in the user's directory gives you is that a user can put custom or modified plugins in their plugins dir and have them read in at runtime instead of having to specify them via commandline options, but if you're doing something as advanced as using custom plugins, maybe specifying those plugins via the commandline is the right solution.

I think autotools is great if you want to support a very diverse range of systems (linux, aix, bsd, cygwin, beos, etc), which is why they're used by all of the GNU projects. But Mupen64-amd64 is being developed and tested only against i686 and x86_64 linux systems, so the range of variations which need to be handled by the build system is not very broad, and the bulk of autotools is unnecessary. If someone really wanted to set up Mupen64-amd64 with autotools and could explain the benefits for adding the complexity to the build system, I would merge it into the SVN tree, but it's not a very high priority for me.

I haven't personally setup an autotools env so I don't know how much bloat it really adds to a system, but as a user of autotools, I think it's very familiar and easy for *nix users to use. Plus, there's already been requests on this forum for a windows and mac osx version of mupen64-amd64. What made me think of autotools originally is all of these flags we're passing to make (NOGUI_ONLY, debug support, lirc support, etc). For multi-user support, we're going to need to add an install prefix option which will have to be set for make and make install. Seems like it'd be a lot easier for the user to pass all of this information to ./configure instaed. Also, the libSDL_ttf issue comes to mind. ./configure can check if this is present and what version they have and print a helpful error message before the user runs into runtime issues.

Another build change that I have been contemplating is unifying the tree by moving the RiceVideoLinux and Glide64 plugins into the main mupen64 build, and maybe removing the broken software gfx plugin. Perhaps this should be synchronized with the rollout of a better name for the fused project than mupen64-amd64. Thoughts?

I think this would be a good move since all of the other plugins are in the main mupen64 tree...if we can come up with a good name. My favorite so far is mupen64+, but I'm kind of boring like that.

 

[Surkow]

[...]

I think this would be a good move since all of the other plugins are in the main mupen64 tree...if we can come up with a good name. My favorite so far is mupen64+, but I'm kind of boring like that.

Mupen64+ sounds like a great name.

 

[Günther1]

No-one has ever taken the time to set this project up with autotools.

If there's interest, I can do this.

 

[TD-Linux]

The binary(ies?) should go into /usr/bin, data into /usr/share, and plugins, well, I dunno... /usr/lib or /usr/share?

Autotools isn't terribly hard. You might want to look into tools like cmake too, if you want something a bit easier.

BTW, I would modify your steps to _always_ have the config file in .mupen64/. Or, I suppose you could check current directory first, but I can't see any reason to have the config files in the current working directory except on Windows.

On *nix, .mupen64 should be always created, either during installation or program start, probably the latter to make cleaning the config easier. Windows again is a special case where the current config file setup can stay.

I can't see a reason why a user would not want a .mupen64. Practically all other *nix programs create . directories, why not us?

 

[ebenblues]

BTW, I would modify your steps to _always_ have the config file in .mupen64/. Or, I suppose you could check current directory first, but I can't see any reason to have the config files in the current working directory except on Windows.

On *nix, .mupen64 should be always created, either during installation or program start, probably the latter to make cleaning the config easier. Windows again is a special case where the current config file setup can stay.

I don't disagree, but Richard42's philosophy is for the user to have a bit more control and say in what the program is doing. I think what I outlined in the initial post is consistent with this and is actually more user friendly than just automatically creating the ~/.mupen64 dir.

My current plan is to have the user specify a prefix directory to make (or ./configure if we get autotools installed) when doing make and make install, e.g. PREFIX=/usr/local. Then make install will copy the mupen64 binary to $PREFIX/bin, and create a $PREFIX/share/mupen64 dir and place the plugins, icons, and language files in this dir (probably in subdirectories). This stays relatively close to the old mupen64 multi-user implementation.

Then I'll modify mupen64 to look for the presence of a $PREFIX/share/mupen64 dir first. If it exists, it will read plugin, icon and language info from that dir. If not, it will default to the old behavior. It will also look for a ~/.mupen64 dir by default for config file info. If it's there, it will use it as the working dir and display a message to the user letting them know this (see my first post for details).

 

[Richard42]

Ebenblues: I suppose I don't have any objections to always using a hidden dir (.mupen64) in the user's home dir if you would rather do it that way. I have a downstream project which uses about 16 different emulators, and most of them use this method.

Gunther: I'd rather stick with something simpler than autotools unless someone really wants it. I would also like to hold off a while either way because I think I'll probably change the source tree around in the near future.

Mupen64+ sounds like a great name.

What about something a little more different, like Mupen64Plus? Or how about Mupen64Cubed? That may fit well since we now have assimilated 3 unique video plugins.

 

[Surkow]

[...]


What about something a little more different, like Mupen64Plus? Or how about Mupen64Cubed? That may fit well since we now have assimilated 3 unique video plugins.

Mupen64Plus also sounds fine. As long as the name reflects that it has more features than the standard Mupen64 program (fixed bugs, new interface, extra plugins, 64bit port etc).

 

[Günther1]

Gunther: I'd rather stick with something simpler than autotools unless someone really wants it. I would also like to hold off a while either way because I think I'll probably change the source tree around in the near future.

Hm, something simpler than "autotools" would be autoconf without automake, but a handwritten Makefile. That would have some of the advantages of configure, like simple out-of-tree-builds or crosscompilation, but none of the bloat of automake.

 

[ebenblues]

Ebenblues: I suppose I don't have any objections to always using a hidden dir (.mupen64) in the user's home dir if you would rather do it that way. I have a downstream project which uses about 16 different emulators, and most of them use this method.

I'm glad you feel that way because as I wrote the code, I realized there was kind of a chicken-and-the-egg problem with my initial design. You can't check/set "Userdir" in the config file because you haven't read it in yet. Also, I can't have a popup dialog asking to create the user dir because the gui hasn't been created at this point in startup.

So I decided to keep it simple, making it use the ~/.mupen64 dir by default without asking the user. If it's not there, it'll create it. Note, this can be overridden using the --configdir option. Also, from your previous post, I separated out the working dir into "config dir" and "install dir". The config dir is used to store user data (conf files, saves, etc). The install dir is where mupen64 looks for common files like plugins, icons, and language files. I think the resulting system will be user-friendly for most linux users. Developers will probably want to use the --configdir and --installdir options to test without having to install.

I also made the code cd to the configdir to get around the problem of blight_input always looking in the current working dir for the conf file. This is a temporary workaround until I can implement the "set conf dir" dll calls in the plugins.