While developing with wxGTK, I like to use the debug build of wxGTK. I didn't
want to have to re-emerge without the "debug" use flag in order to get a release
build for building my releases though.
I created a "builddebug" use flag in the wxGTK-2.6.1 ebuild that can be
specified to install both the debug and release builds at the same time.
Steps to Reproduce:
1. Copy new ebuild to /usr/local/portage/x11-libs/wxGTK
2. echo "x11-libs/wxGTK builddebug" >> /etc/portage/package.use
3. emerge -av wxGTK
#> wx-config --list
Default config is gtk2-unicode-debug-2.6
Default config will be used for output
Created attachment 68867 [details]
Ebuild with builddebug use flag
I'm not an ebuild expert. This works for me though. Probably needs some
review before (or if) can be added to portage.
i was looking for something like that.
I made a version for wxGTK-2.6.2-r1 ebuild.
i just added a --enable-debug_gdb in the configure for the debug build.
and i put the install of the debug in first to have /usr/bin/wx-config links to the gtk2-unicode-release.
Created attachment 77074 [details]
wxGTK-2.6.2-r1.ebuild with builddebug
*** Bug 117866 has been marked as a duplicate of this bug. ***
Would SLOT'ing on debug perhaps work out?
E.g, 2.6 SLOT for when no debug USE flag, 2.6-debug SLOT when debug USE flag, with all problems sorted out that may arise on the co-existance (wx-config, et cetera)
Sounds like it would work just fine to me. Would the slot fill a virtual/wx-2.6 space? You could have either one or both installed, is that correct?
It is just an initial idea noted from my part, that perhaps some more knowledgable person regarding ebuild handling might shoot down before I shoot myself in the foot.
My ideas go in the lines of striving towards having all wxGTK dependent apps work against unicode, and demand for that then. The SLOT would be utilized as a different way to have co-existing different settings builds. Before gtk1/2 co-existance was handled by USE flag hell which is gone now in latest stable ebuild. I think SLOTs might work out better for allowing all of the following builds co-exist all in different slots:
I have no interest for gtk1 versions of all those.
Packages could use the wxwidgets eclass to select a suitable build, and instruct the user to install a wxGTK that meets demands, if a suitable one isn't installed yet. The dependency on wxGTK would pull in a wxGTK that might not be suitable, and the user will have to pull in another and the former was unnecessary.
Ugly like that until portage supports USE depends.
If someone would be able to comment on the feasibility of this idea, I'd be glad.
Not much ugliness with debug and release SLOTs, as it will suit either way to the app, but is more problematic for the unicode vs ansi ordeal.
Slots can't be dynamic like that. They need to be entirely deterministic and not depend on USE flags.
I recalled a USE flag in the toolchain that made micro versions go to different SLOTs, instead of merely minor versions, hence the idea from there.
Yea, we do have that, and it is wrong there as well :)