gcc-config is about the only such tool that hasn't been converted to eselect yet. (I am aware of eradicator's old compiler.eselect, and I am _not_ suggesting to take any code from it as a starting point. Also, I guess enough time has passed that most people don't remember it any more. ;-)
> gcc-config is about the only such tool that hasn't been converted to eselect yet. What is about binutils-config?
i don't plan on looking into eselect as a replacement because it's ridiculously slow. would probably be easy to add a simple module though as a frontend to gcc-config. something that'd provide the list/set options.
(In reply to SpanKY from comment #2) > i don't plan on looking into eselect as a replacement because it's > ridiculously slow. Why would that be the case? Both gcc-config and eselect are written in bash, and AFAICS the internal logic of gcc-config could be kept. The whole point of converting it into an eselect module would be to provide a uniform user interface. Or what am I missing? (In reply to Markus Rathgeb from comment #1) > What is about binutils-config? eselect binutils exists.
> Why would that be the case? Both gcc-config and eselect are written in bash, > and AFAICS the internal logic of gcc-config could be kept. The whole point > of converting it into an eselect module would be to provide a uniform user > interface. Or what am I missing? IIUC because eselect isn't part of @system it won't be available when bootstrapping. So we can't get rid of gcc-config altogether. Given that, I think making the module a frontend to gcc-config makes more sense than duplicating the functionality.
(In reply to Ulrich Müller from comment #3) i haven't looked into why eselect is slow because i don't care. everytime i have to use it (for interacting with other tools), it's unreasonably pokey. i'm not going to force that onto users. having an eselect compiler shim that calls gcc-config satisfies your "uniform user" interface. as for binutils-config, it's the same answer. the fact that someone else wrote a module doesn't matter that much when all the binutils ebuilds/etc... call binutils-config. any filesystem based poking that eselect module does is not guaranteed ABI of binutils-config, so it might break.
i've added such a wrapper module now and it'll be in the next version: http://gitweb.gentoo.org/proj/gcc-config.git/commit/?id=db595876a93d194b2ac98c9e1804d0772edb1635 i see no reason to delete gcc-config and merge it entirely into eselect. the requirement is that `eselect gcc` can show/list/change active toolchains and the wrapper module accomplishes that. and on the `eselect binutils` front, it does indeed look like it's already broken and out of sync with the current code. that should really be deleted so we can add the wrapper module to binutils-config package.
(In reply to SpanKY from comment #6) > and on the `eselect binutils` front, it does indeed look like it's already > broken and out of sync with the current code. that should really be deleted > so we can add the wrapper module to binutils-config package. Please drop me a note whenever the binutils wrapper module is ready. I will then remove the bundled binutils module from eselect proper and make a new release.
(In reply to Ulrich Müller from comment #7) i've committed binutils-config-4-r4 now w/the eselect module, albeit with KEYWORDS disabled. feel free to uncomment that when you add the new eselect.
(In reply to SpanKY from comment #8) - eselect-1.4.5 without binutils module committed to tree - binutils-config-4-r4 keywords added and blocker updated to !<eselect-1.4.5
