It would be really nice if crossdev had the ability to: 1. list installed targets 2. query a particular target and show it's info (this can just be a front end to emerge --info ${TARGET}/{gcc,binutils,gdb,glibc}) 3. in general, (attempt to) treat each target as the logically autonomous entities that they are 4. Possibly, some debug options to help find remnants of toolchains that didn't get properly cleaned up (yes, I've had lots of this over the years) or simply list all files, directories, etc. related to a toolchain. I can see that a similar bug report got a WONTFIX (bug #488668). However, I am hoping that you guys can see the value in this, especially for somebody who does a lot of embedded development and has to manage a lot of different toolchains. Thanks for an awesome program!
(In reply to Daniel Santos from comment #0) > It would be really nice if crossdev had the ability to: > > 1. list installed targets gcc-config -l binutils-config -l > 2. query a particular target and show it's info (this can just be a front > end to emerge --info ${TARGET}/{gcc,binutils,gdb,glibc}) ARCH-VENDOR-OS-LIBC-emerge --info > 3. in general, (attempt to) treat each target as the logically autonomous > entities that they are Pardon? > 4. Possibly, some debug options to help find remnants of toolchains that > didn't get properly cleaned up (yes, I've had lots of this over the years) > or simply list all files, directories, etc. related to a toolchain. Use any of the app-portage/* tools to list installed packages so you can remove them? Clean up your world file? crossdev is a wrapper around emerge, so anything it does can be undone through emerge.
crossdev & tools already clean up known things. if it isn't being cleaned, it's because it isn't known, and trying to teach the tool to scan the system won't really help. if you know of specific files left behind, then please file a sep bug listing the exact paths.
It's been a while as I got busy with other things, but here are the files left behind and the steps I followed. (I ran crossdev back in 2014, but I think I retried it last year too.) # crossdev --stage4 --ex-gdb -t armv6j-hardfloat-linux-gnueabi IIRC, the build failed on stage4 and, thus, never got to gdb. # emerge -C cross-armv6j-hardfloat-linux-gnueabi/{binutils,gcc,glibc,linux-headers} This ran fine. # ll $(find /var /usr/local /etc/ -iname '*cross-arm*' |egrep -v '/var/log/portage|/var/cache/edb/') -rw-r--r-- 1 root root 469 Aug 2 22:58 /etc/portage/package.env/cross-armv6j-hardfloat-linux-gnueabi -rw-r--r-- 1 root root 342 Aug 2 22:58 /etc/portage/package.keywords/cross-armv6j-hardfloat-linux-gnueabi -rw-r--r-- 1 root root 368 Aug 2 23:20 /etc/portage/package.use/cross-armv6j-hardfloat-linux-gnueabi -rw-r--r-- 1 root root 272 Aug 2 22:58 /etc/portage/profile/package.use.force/cross-armv6j-hardfloat-linux-gnueabi -rw-r--r-- 1 root root 272 Aug 2 22:58 /etc/portage/profile/package.use.mask/cross-armv6j-hardfloat-linux-gnueabi -rw-r--r-- 1 root root 53 Aug 2 22:58 /etc/revdep-rebuild/05cross-armv6j-hardfloat-linux-gnueabi /etc/portage/env/cross-armv6j-hardfloat-linux-gnueabi: total 28 drwxr-xr-x 2 root root 4096 Aug 2 22:58 ./ drwxr-xr-x 3 portage portage 4096 Aug 2 22:58 ../ -rw-r--r-- 1 root root 676 Aug 2 22:58 binutils.conf -rw-r--r-- 1 root root 676 Aug 2 22:58 gcc.conf -rw-r--r-- 1 root root 676 Aug 2 22:58 gdb.conf -rw-r--r-- 1 root root 601 Aug 2 22:58 glibc.conf -rw-r--r-- 1 root root 601 Aug 2 22:58 linux-headers.conf /usr/local/portage/cross-armv6j-hardfloat-linux-gnueabi: total 8 drwxr-xr-x 2 portage portage 4096 Aug 2 22:58 ./ drwxr-xr-x 10 portage portage 4096 Oct 25 04:06 ../ lrwxrwxrwx 1 portage portage 31 Aug 2 22:58 binutils -> /usr/portage/sys-devel/binutils/ lrwxrwxrwx 1 portage portage 26 Aug 2 22:58 gcc -> /usr/portage/sys-devel/gcc/ lrwxrwxrwx 1 portage portage 26 Aug 2 22:58 gdb -> /usr/portage/sys-devel/gdb/ lrwxrwxrwx 1 portage portage 27 Aug 2 22:58 glibc -> /usr/portage/sys-libs/glibc/ lrwxrwxrwx 1 portage portage 37 Aug 2 22:58 linux-headers -> /usr/portage/sys-kernel/linux-headers/ So /var/cache/edb/... will clear up after /usr/local/portage/cross-armv6j-hardfloat-linux-gnueabi/* are removed and the database is rebuilt (eix-update or something), but the rest is the cruft I was referring to. (In reply to SpanKY from comment #2) > crossdev & tools already clean up known things. if it isn't being cleaned, > it's because it isn't known, and trying to teach the tool to scan the system > won't really help. if you know of specific files left behind, then please > file a sep bug listing the exact paths. I don't think that a separate bug is appropriate because I believe that my proposed solution is the cleanest -- simply *track* what crossdev has installed and provide a *wholistic* ability to manage those toolchains. I can run gcc-config -l to see what gcc and and binutils-config -l to see what binutils I have installed. For that matter, I can just run qlist -IC cross-armv6j-hardfloat-linux-gnueabi/ to see all of the packages, but I don't have a way to remove *an entire toolchain* -- as a single entity -- and also have the cruft cleaned up. crossdev is already managing each toolchain as a single entity in some ways by creating the directory $PORTDIR_OVERLAY/cross-$TARGET/ and associated package symlinks. I'm simply proposing a solution to the cruft problem that can also enable some "nice to have" query options. But first and foremost, it shouldn't leave clutter that requires the user to gain an intimate understanding of how crossdev works to ensure that they don't break their system by attempting to remove it. So perhaps crossdev can create some file under /var/db/crossdev to track what it has installed?
(In reply to Daniel Santos from comment #3) > emerge -C ... that's your problem. you're doing it wrong ... > but I don't have a way to remove *an entire toolchain* -- as a single entity -- and also have the cruft cleaned up. yes, you do. that's the entire point of `crossdev -C <tuple>` which has existed forever. > So perhaps crossdev can create some file under /var/db/crossdev to track > what it has installed? crossdev already tracks everything it installs & removes them. i don't know what exactly you expect here. a flat text file of every path crossdev touched and then we process that when cleaning ? there's no material difference between that and what we do today -- crossdev is a text file that knows every file it touched and what to remove. the fact that somethings were missed as part of the removal is a bug, and the bug would have existed exactly the same as if we forgot to list that file in this /var/db/crossdev setup in the first place. we can add a -l/--list option to list tuples i guess ?
