clockworkpi

Streamlining Retroarch ./configure options

I admit.
I just do a brute force style installation, not disabling anything whenever I build my Retroarch. This results in it being relatively bloated, potentially starting up slower and when giving it to other people to use, prone to someone changing settings that aren’t supported by the gameshell.

Recent efforts by @Joao_Manoel has us using Bullseye as the Debian distribution, and has liaised with other external developers on kernel optimisation and development. Well done!

The current version of Retroarch is 1.8.8, and a few higher than the stock one, and the current one for anyone building today.

Now. The point of this post is to potentially discuss how to set things up to a standard that matches today’s gameshell. The mega thread was an extremely broad thread for the older system. It is quite out dated; although a lot of it is still applicable. It did however end up being a trouble shooting thread for people, and any real discussion basically stopped.

First and foremost, this is the dirty way that I build up Retroarch.

sudo apt-get install git build-essential
sudo apt-get build-dep retroarch
git clone https://github.com/libretro/RetroArch.git retroarch
cd retroarch
./configure
make -j2
sudo make install

I just omit setting up the build environment (first two lines) when doing an update over an existing version.
The number of jobs I have is set to -j2, despite having a quad core system. This is because occasionally it will indefinitely hang when using -j4; unless you set up a swap disk. Second, if also gets pretty hot. I actually melted my shell a little building while in a bag. Completely my fault.

The ./config is where I’ve been lazy and not provides any options to enable, disable or other wise specify any other installation parameters.
The previous mega thread for Retroarch mentions a few things to disable, but with Lima drivers working, the aforementioned advances in the state of things on the gameshell and new options potentially existing in a newer Retroarch version, we may need to revise this.

Second, having a config file that is standardised applied during installation would help to streamline installation. The problem lies in changes in versions resulting in more/revised options within the Retroarch.cfg file. I am always dubious about using configs from older releases in newer releases, so usually just redo my configs from scratch each time to make sure nothing goes wrong.
Perhaps having the configs updated using a diff file of sorts can make sure standard things aren’t omitted, while keeping newer options and potential compatibility issues under wraps.

Third, whether or not it would be worthwhile to have an updated base core list, specifically compiled for the Gameshell. It’s a timely process, and if we could actually have a custom repository set up that is somewhat community maintained, if could definitely be beneficial, and completely modular in its upgradeability.
It would be a huge undertaking to do all of them, so it might be worthwhile to bring up some discussions re: which cores the community finds useful as a whole.

Lastly, the “flavour” of OS to be used. I brought up this topic in its own thread, since it is something that can be useful of people, regardless of which operating system we are using. There are so many more options now, and it is exciting to say the least. Of course, some options within retroarch.cfg would need to be catered to individually, eg core directories.

This should be something that anyone can use on their gameshell. We should have roughly the same hardware, so our mileage shouldn’t differ too much. Still. If would be worthwhile to share results of different changes made, and to make it standardised. This isn’t something that can be taken on singlehandedly by one person.

Right. So with that said, I guess the first question is, does anyone have a more effective installation method, and have a good idea of what does and doesn’t work?

It would be great to put together a table of sorts, outline all of the instructions available to the CPI, and existing driver across different operating system. Cross referencing this with the Retroarch build options would make customising installations much easier.

Hopefully the intent of this thread actually makes sense
If possible, try not to post request for help, (eg, “I tried installing but it doesn’t work”) or requests for where to download the latest configs etc. That’s not what this thread is about. Use the old thread for that.

This is for standardising Retroarch for the gameshell.

2 Likes

up to date,thank you.