ES devs and testers, this tool is for you!

[Hex]

"Do you want to install"... triggers apt-get. I use fedora which uses dnf so the command to install fails.

I would like the script to check if apt-get is present else is dnf present and then use that accordantly. If both fail you can get the executable from github (optional)

jq 1.5 is in the official Debian and Ubuntu repositories. Install using sudo apt-get install jq.

jq 1.5 is in the official Fedora repository. Install using sudo dnf install jq.

jq 1.4 is in the official openSUSE repository. Install using sudo zypper install jq.

jq 1.5 is in the official Arch repository. Install using sudo pacman -Sy jq.

[meleu]

@Hex Well, it's intended to be used on a Debian-based distro (just like RetroPie is). But I'll add a warning if apt-get is not found.

[meleu]

@Hex Done. If the script can't find apt-get, the user will see this dialog:

[Zigurana]

Feature request: Build and install based on a current PR number.
Rationale: lower the barrier even more: users do not need to hunt for the correct repo + branch, if they only know the GitHub PR number.

[meleu]

@zigurana got it. I'll try to implement it this weekend. ;)

[darknior]

Woaw excellent, i didn't see this ES test project before, i love it, so easy and fast to test branch :)
Thanks a lot to make it...

[meleu]

@zigurana said in ES devs and testers, this tool is for you!:

Feature request: Build and install based on a current PR number.
Rationale: lower the barrier even more: users do not need to hunt for the correct repo + branch, if they only know the GitHub PR number.

What do you think if we use the PR number rather than a sequential number in the menus? Is it enough?

Like this:

[Zigurana]

Wow! That was fast! Man, you are ever dependable!
I love it!
I think the PR number is clear enough to understand, no need to re-number them in the script.

Will this exist alongside the current method of manually specifying a repository and branch? That would be usefull for things that are not yet PRs.
[EDIT:]
Oh wow, I am an ass. I just now see that you already had the function to get the current list of open PRs! Since June! Never mind me, I should have actually updated the tool, I guess. </shameface>

In any case, this new improvement is a bit of cosmetics that will not hurt anyone. At least now it's absolutely clear what PR folks are installing.

So cool of you to jump on this so quickly! Thanks!

[darknior]

@meleu said

Now look at this menu:

Yes thanks i forgot this, i can come back to the master branch.
Is there a way to compile MASTER branch with your script, it is faster than in Retropie-Setup because you are not removing sources files. I have think to add the GIT of the master branch to compile it like a beta, but maybe you already code something for it ?

[meleu]

@darknior said in ES devs and testers, this tool is for you!:

Is there a way to compile MASTER branch with your script, it is faster than in Retropie-Setup because you are not removing sources files. I have think to add the GIT of the master branch to compile it like a beta, but maybe you already code something for it ?

Maybe I can take a look at it later. Quite busy currently.

Thanks for the feedback! ;-)

[Hex]

@meleu Option to compile "master" and "stable". Master is currently a dev branch.

[darknior]

@hex There are some "master" branch, but i don't see the official.
Only eagleOwl n Joemommasfat. But i think i can add it like any branch ?

[RichardBr]

Thank you for sharing, I was looking for this :D

[atfrase]

This script was last updated 4 years ago now, but since the topic is still pinned, a few notes for anyone coming upon it more recently:

It does not appear to work correctly on a Pi 4; the emulationstation binary compiled via this script exits immediately with the message "failed to add service - already in use?" I suspect this is because the Pi 4 uses a different graphics driver and this script is not setting the correct OPENGL compiler directive, but I haven't been able to find where to change that to confirm that it fixes the problem.

A lesser issue is that it cannot add custom branches to its list because it attempts to validate them by looking for "Status: 200" in a HEAD request to github, but the modern response is "HTTP/2 200". This is easily fixed by just searching the script for that test and changing the grep pattern to "^(HTTP/2|Status:) 200".

Other Pi 4 users can try this less elegant workaround for testing a single specific repo/branch: edit RetroPie-Setup/scriptmodules/supplementary/emulationstation-dev.sh and change the rp_module_repo= to point to your desired branch, and then just install emulationstation-dev from source under the experimental modules in retropie_setup.sh. As a bonus, you can also edit the base emulationstation.sh to remove the make clean call (or skip it depending on an env var such as $__persistent_build), to avoid recompiling all the unchanged objects each time.

[meleu]

@atfrase wow! 4 years! 😱

yeah, indeed... I don't play with this script for years... but if EmulationStation development is still hot and my script can be useful for devs and testers, I'd be happy to restart working on it.

@BuZz @mitu @pjft and @eshackers, could you guys confirm that for me?

(I'm currently using bash intensively in may dayjob, so it would be fun to revisit my code from 4 years ago 😅)

[mitu]

@meleu said in ES devs and testers, this tool is for you!:

but if EmulationStation development is still hot

Not so much these days.

The script could probably be simplified, since there is branch support in RetroPie-Setup scriptmodules directly and RetroPie-Setup automatically checks for new changes to the branches (letting you know if you should update from source or have the latest source version).

P.S. Happy New Year !