We use wxwidgets not only to build other gentoo packages, but also for local development. However, for local development, we require a minor modification to the current wxwidgets profile. This modification confuses the emerge of some gentoo packages (codeblocks and cmake-based builds using wxwidgets). Hence, we would need separate user and system settings for the eselect wxwidgets profile: "system" for emerging packages, "user" for local development.
wxwidgets eselect choice is meant to ONLY affect "user" local development. It must not have any effect whatsoever for package builds, which must honor the choice made in WX_GTK_VER.
Please expand on the problem and modifications you are mentioning. Otherwise this feels like INVALID or WORKSFORME, and perhaps a problem in codeblocks or your "minor modifications"
Ok, now I understand how things should work and should be done. What we did was editing the default profile installed by emerge wxGTK. The reason why we directly modified the default profile instead of adding a new one is that we believed that eselecting a new profile and modifying the default profile both has the same effect for both users and emerging packages (which is not true according to your answer: emerges are independent of the eselected profile?!). The reason we believed this is that the "eselect wxwidgets" help text for "set" says "Set the *system* wxWidgets profile", which made us assume that it also influences emerges. Perhaps that help text should be changed?! What we modified in the default profile and why: The wx header files are of rather poor quality: If a wx project is compiled with -Wall -Wextra and several more -W, it gives you hundreds of warnings pointing to problems within the wx headers, not your project. To stop that nonsense warnings, we replaced the "-I" in the definition of "_include_cppflags" and "_cppflags" with "-isystem". "-isystem" has exactly the same effect as "-I", but suppresses all warnings for headers from those dir's. This solved our problems, but caused some ebuilds to break. So we should not touch the original profile, install a modified copy, eselect that, and everything should work? (i.e. all emerges still use the unmodified original, not the eselected one?)
emerges effectively use a specific eselect profile, but what profile they use depends on what the ebuild sets (typically via WX_GTK_VER variable before inherit wxwidgets). The eselect machinery picks up a special env var set by the eclass and forces that profile, instead of what user has selected as system profile for own use. If you look at /usr/bin/wx-config, you'll see it honoring a WX_ECLASS_CONFIG env var if set, and only falls back to eselect choice if it isn't set. And the wxwidgets.eclass sets that env var in setup-wxwidgets call. So if you modify the 3.0-gtk3 eselect-wxwidgets profile, it'll affect all ebuilds setting WX_GTK_VER="3.0-gtk3" as well.
I understand. That should satisfy all our needs. I just checked: Every wx-dependant package I've emerged sets WX_GTK_VER, so none of them should be influenced by eselect. So creating our own profile and eselecting that, and not modifying the standard profiles, will work for all ebuilds we have installed (using the standard profiles) and for our own work (using the eselected profile). Only remaining thing: Perhaps improve the "Set the *system* wxWidgets profile" help text of "eselect wxwidgets"?
What do you suggest to change it to? The "system" of it is about it applying to the whole system - as in, to all users on the system
"Set the wxWidgets profile to use outside portage" or something like that? In fact, the log msg text in the eselect-wxwidgets ebuild is really informative, too bad that noone checks emerge logs of successful emerges... (I also just found it this morning by looking at the ebuild)
