ps3dev / PSL1GHT

A lightweight PS3 SDK
www.psl1ght.com
MIT License
226 stars 64 forks source link

Make the project packageable with DESTDIR variables. #138

Closed disc-kuraudo closed 1 year ago

disc-kuraudo commented 1 year ago

For packaging with e.g. $ make DESTDIR="${pkgdir}" install as done here: https://aur.archlinux.org/packages/ps3-psl1ght-rules https://aur.archlinux.org/packages/ps3-psl1ght

Practically any Makefile out there supports this.

On a side note: I updated the ps3toolchain to gcc 9.5.0 (PPU/SPU) and binutils 2.40 (PPU) there. Feel free to update the toolchain with my updated patches.

miigotu commented 1 year ago

The PSL1GHT variable IS DESTDIR for psl1ght, so I don't understand the usage of this. Same with PS3DEV, which is the DESTDIR for ps3dev

disc-kuraudo commented 1 year ago

The PSL1GHT variable is the prefix. E.g. when set to /opt/ps3dev/psl1ght, when building it's impossible to write to there as non-root, that's why you shift it to DESTDIR (e.g. ${PWD}/pkg -> ${PWD}/pkg/opt/ps3dev/psl1ght) temporarily in a custom environment to package it, then the package manager takes it from there to install it on any machine into the actual prefix. https://www.gnu.org/prep/standards/html_node/DESTDIR.html Many such cases.

If unset, e.g. when invoking the psl1ght script in ps3toolchain, it doesn't change a thing.

zeldin commented 1 year ago

@disc-kuraudo What miigotu is saying is that you for example want a "prefix" of /opt/ps3dev/psl1ght and a "DESTDIR" of /tmp/build/psl1ght/image, then you can build with $PSL1GHT set to /tmp/build/psl1ght/image/opt/ps3dev/psl1ght (or just /tmp/build/psl1ght/image if you prefer that). After install, your package system can move it to /opt/ps3dev/psl1ght, /home/disc/psl1ght or whereever, and it will still work. There is nothing in what is installed that contains the build value of $PSL1GHT. When you use psl1ght, you set $PSL1GHT to wherever it is now.

disc-kuraudo commented 1 year ago

Nope, not working as expected during install:

make PSL1GHT="${pkgdir}${PSL1GHT}" install
[...]
'include/usb' -> '/build/ps3-psl1ght/pkg/ps3-psl1ght/opt/ps3dev/ppu/include/usb'
'include/usb/usb.h' -> '/build/ps3-psl1ght/pkg/ps3-psl1ght/opt/ps3dev/ppu/include/usb/usb.h'
Makefile:11: /build/ps3-psl1ght/pkg/ps3-psl1ght/opt/ps3dev/ppu_rules: No such file or directory
make[2]: *** No rule to make target '/build/ps3-psl1ght/pkg/ps3-psl1ght/opt/ps3dev/ppu_rules'.  Stop.
make[1]: *** [Makefile:18: install] Error 2
make: *** [Makefile:36: install] Error 2

Note: the _rules were installed as a separate package since make to build this expects these to be in ${PSL1GHT} already.

Faking this variable for this purpose makes a mess. Will keep pointing the package to my branch until there is something that works to package this.

zeldin commented 1 year ago

@disc-kuraudo You need to have the same value (/build/ps3-psl1ght/pkg/ps3-psl1ght/opt/ps3dev) in $PSL1GHT for each of the steps make install-ctrl, make and make install. Then it will work. You are not "faking" the variable, you are using it to tell the build process where you want the result, which is the purpose of the variable.

miigotu commented 1 year ago
export PSL1GHT="/tmp/opt/psl1ght" 
make install-ctrl
make
make install 

You can then:

zip /tmp/opt/psl1ght

extract it to /opt/psl1ght (on another system)

export PSL1GHT="/opt/psl1ght"
make install-ctrl
make
make install
miigotu commented 1 year ago

Nope, not working as expected during install:

make PSL1GHT="${pkgdir}${PSL1GHT}" install
[...]
'include/usb' -> '/build/ps3-psl1ght/pkg/ps3-psl1ght/opt/ps3dev/ppu/include/usb'
'include/usb/usb.h' -> '/build/ps3-psl1ght/pkg/ps3-psl1ght/opt/ps3dev/ppu/include/usb/usb.h'
Makefile:11: /build/ps3-psl1ght/pkg/ps3-psl1ght/opt/ps3dev/ppu_rules: No such file or directory
make[2]: *** No rule to make target '/build/ps3-psl1ght/pkg/ps3-psl1ght/opt/ps3dev/ppu_rules'.  Stop.
make[1]: *** [Makefile:18: install] Error 2
make: *** [Makefile:36: install] Error 2

Note: the _rules were installed as a separate package since make to build this expects these to be in ${PSL1GHT} already.

Faking this variable for this purpose makes a mess. Will keep pointing the package to my branch until there is something that works to package this.

I think you are expecting the PSL1GHT variable to provide some hardcoded linker path, which is actually set relatively in the whole toolchain. If you build psl1ght in one location, and then completely change the location to the toolchain you just change the value of PSL1GHT to match the new location.

disc-kuraudo commented 1 year ago

The temporary package directory only exists in the package() step, anything else would be weird, because you can't even tell what the package directory is as you could split it into several sub-packages from one build(), as done in e.g. the gcc package.

So building like that in the build() step won't work as the temporary package directory doesn't exist, that's why I had to resort to a separate -rules package. After building I would have to invoke make install-ctrl before make install with both pointing to the temporary package directory and I'd then need to remove the *_rules again as they already exist in the -rules package.

It's all good if you play around with this in your ${HOME} or with sudo using the scripts, totally unmanaged (unpackaged).

Anyway, I found a workaround to build and package this in one go (w/o a -rules package) with the upstream Makefile:

What a waste of my time. Closing.

miigotu commented 1 year ago

I wouldn't say it's a waste of your time, sometimes it just helps to have the people who have been maintaining a project for 10+ years understand exactly what your reasoning is.

You don't necessarily need to reinvoke install-ctrl, as long as you set the paths relative or add a variable in the variable definition of PSL1GHT itself.

Anyway, I hope a minor disagreement or misunderstanding doesn't discourage you from contributing in the future.