This question relates to ebuild development, and is being asked by a
non-developer. Apologies if there's a better forum for the question
(perhaps gentoo-toolchain?)
I've developed an ebuild for a package which requires GCJ >= 3.4.2
(GCJ is specifically required for its ability to translate Java to C
for embedding).
I run a x86-stable desktop, so my profile's basic GCC is at 3.3.5
(which was built without a GCJ use flag). I've installed a 3.4.3 GCC
with GCJ using slots.
Are there any suggestions for how my ebuild might identify whether
there is a GCC installed, in any slot, which matches both the version
requirement (>3.4.2) and the "gcj" USE requirement?
The ebuild has this:
DEPEND="${RDEPEND}
>=sys-devel/gcc-3.4.2"
which succeeds since that is installed. I also have this block
commented out in my ebuild:
#pkg_setup() {
# if [[ ! $(built_with_use gcc gcj) ]] ; then
# eerror 'Chandler build requires that GCC be built with the "gcj" USE
flag'
# die "exiting because of GCJ dependency"
# fi
#}
If I uncomment it, this block will fail because my 3.3.5 GCC isn't
"built_with_use" gcj and I think "best_version" (which built_with_use
uses) only looks at my 3.3.5 installation. Even if I 'gcc-config' the
3.4.3 version, best_version still looks at my 3.3.5.
My goal is to make this ebuild find and use a working GCC if it is
present, even in the presence of slots and mixed use flags.
I'm not sure this is possible without some fairly serious scripting.
Suggestions are welcome.
One improvement might be to replace the built_with_use check with
something like a `gcc-config -B`/gcj check, and check at runtime that
it's version 3.4.2 or higher. That seems straightforward.
I might also look at every profile returned by `gcc-config -l`, and
try them one at a time until I found one that works. That's sort of
what I want to encode, but may be more scripting than it is worth.
Are there any other options, eclasses, or general approaches I should
consider for this problem?
Thanks for your time.
-- [EMAIL PROTECTED]
"One cannot mark the point without marking the path."
--
[email protected] mailing list
