aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* dev-scheme/guile: multilib-utizeGregory M. Tuner2014-01-264-14/+100
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A nontrivial multilib-utization. First, I have made a couple of non-multilib-related fixes: * pass serial-tests to AM_INIT_AUTOMAKE, since otherwise, eautoreconf completely breaks src_test * don't actually fail when tests fail, since, even though we've fixed the tests to run, several tests still don't pass and fixing the mess looks nontrivial. Clearly, there is more work to be done here. Multilib-utization-related changes: * During src_install, building out of tree changes things somehow so that the Makefile tries to remove the file /usr/bin/build-guile, during the installation of the guile-config target. Formerly (before multilib-utization), it would try to remove ${ED}/usr/bin/build-guile, which, although unnecesary and kind of ugly, was a noop. Somehow, building out of tree changes a variable used to no-longer include $(DESTDIR). In practice, there probably is no /usr/bin/build-guile. If there were one, it might or might not be the out-of-date file that the Makefile wants to remove. Anyhow, I didn't worry about that, but just took measures to ensure the Makefile target will not attempt to remove the file. * Hacks up generated non-best-ABI makefiles so as not to peform the rather lengthy doc generation process. Unfortunately this required a bit more sed hackery than I usually like to implement in an ebuild, but this was mostly due to trying to implement the hacks in a manner likely to be fairly stable in the face of future changes. * We can't @wrap guile-config as it is an identical guile script on all targets. @wrapping /usr/bin/guile would work but I am pretty keen not to @wrap core development- toolchain elements like that. So what I did was the following: o no-@-wrap /usr/bin/guile so that we get guile-{ABI} executables in /usr/bin along-side the best-abi /usr/bin/guile with no 'funny-business' o hack-up the shebang in the per-abi /usr/bin/guile-config executables to refer to the corresponding /usr/bin/guile-${ABI} -- however, this is only done when more than one ABI is being built (otherwise, the executable wrappers have no effect, and therefore, there would be no /usr/bin/guile-${ABI}. o @-wrap /usr/bin/guile-config (which now has the desired effect since the shebangs of the abi-specific wrapped /usr/bin/guile-config-${ABI} executables refer to the correspondig /usr/bin/guile-${ABI}. This is still not exactly wonderful for at least three reasons: first, it creates a binary wrapper which in turn executes shebang-ified script executables -- sooner or later, somebody will probably find some case for which there is no OS support for that; second, it's fairly obscure and confusing; third, if anyone tries to run the script directly from the interpreter instead of relying on the shebangs and the intrinsic binary loading machinery to get their result, this will break (this third concern is the most plausible source of problems, I suspect). A far better solution would be to add scripted code to check for the MULTILIB_BUILD_ABI variable and act accordingly based on its value. I used to know scheme but that was many years ago and I'm frankly sick of screwing around with this ebuild. If anybody is found to attempt to load guile-config, then we could just hack up those programs to load the correct multilib wrapper directly, in their respective ebuilds, if we are still to lazy to implement a multilib-build-aware guile-config in scheme. A last-resort would be to @wrap the guile executable; hopefully that won't be required. Signed-off-by: Gregory M. Tuner <gmt@be-evil.net>
* dev-scheme/guile: clone upstreamGregory M. Tuner2014-01-268-0/+967
Signed-off-by: Gregory M. Tuner <gmt@be-evil.net>