search

devkitPro / pacman

GNU General Public License v2.0
168 stars 16 forks source link

Removing gba-dev doesn't remove devkitarm-rules. #24

Closed luckytyphlosion closed 3 years ago

luckytyphlosion commented 3 years ago

sudo dkp-pacman -R gba-dev won't remove the files related to devkitarm-rules, even though gba-dev depends on devkitarm-rules. This is a minor issue with Makefiles that check if $(DEVKITARM)/base_tools exists (where $(DEVKITARM) may still exist depending on the user's specific setup to set the variable), because base_tools will be included but will be of no use.

WinterMute commented 3 years ago

Why do you want to remove the gba-dev group?

endrift commented 3 years ago

You need to use -Rcs if you want to remove unused dependencies. pacman doesn't do that automatically.

luckytyphlosion commented 3 years ago

You need to use -Rcs if you want to remove unused dependencies. pacman doesn't do that automatically.

Ah thanks, I didn't know I was missing some command flags.

Why do you want to remove the gba-dev group?

It was recently re-discovered that it is possible to build the gen 3 decompilations without dkA much more effortlessly on Debian-based Linux distros (which includes Windows 10 using WSL) since they provide binutils-arm-none-eabi as a package, so I needed to test building without dkA installed. There are a few conditions where $(DEVKITARM) would still be set even after removing packages (msys2 environment variables which exist within WSL, if the devkitPro env. variables were exported manually to ~/.bashrc), which is how I ran into the error. Although, given that I wasn't properly uninstalling gba-dev, it is probably not a real issue anyway.

WinterMute commented 3 years ago

You have no need to uninstall devkitPro supplied tools in order to use a different set of arm-none-eabi tools. This makes zero sense.

We quite deliberately do not recommend adding our toolchains to the system path for this very reason.

If you want to use the system arm-none-eabi binutils on linux (including WSL) then all you have to do is use the tools already in path. You shouldn't be depending on the devkitPro supplied system variables.

luckytyphlosion commented 3 years ago

You have no need to uninstall devkitPro supplied tools in order to use a different set of arm-none-eabi tools. This makes zero sense.

I was testing the Makefile setup as if I did not have devkitPro installed. You can find the new configuration here.

We quite deliberately do not recommend adding our toolchains to the system path for this very reason.

I'm not sure where I ever implied this.

If you want to use the system arm-none-eabi binutils on linux (including WSL) then all you have to do is use the tools already in path. You shouldn't be depending on the devkitPro supplied system variables.

Right now the Makefile first checks for $(DEVKITARM), and if it isn't found, then it will assume that the user has the binaries within the path. I'm not an expert in Unix/POSIX/whatever buildsystems, so I'm open to suggestions as to how to improve this.

WinterMute commented 3 years ago

I was testing the Makefile setup as if I did not have devkitPro installed. You can find the new configuration here.

You don't ever have devkitPro installed. devkitPro is an organisation, we supply tools & libraries that allow amateur programmers to build code for a variety of game consoles. You cannot install us, only our tools and libraries.

If you want to test how your build system behaves when unable to find devkitARM then perhaps, rather than removing binaries, it might be better to just unset the environment variables you're checking in the shell where you're testing ...

If you want to use the system arm-none-eabi binutils on linux (including WSL) then all you have to do is use the tools already in path. You shouldn't be depending on the devkitPro supplied system variables.

Right now the Makefile first checks for $(DEVKITARM), and if it isn't found, then it will assume that the user has the binaries within the path. I'm not an expert in Unix/POSIX/whatever buildsystems, so I'm open to suggestions as to how to improve this.

Try not to assume things. Check everything. Think about the order you do that.