dev-scheme/gambit-4.0_beta17 has been released. Please update portage.
*** Bug 151313 has been marked as a duplicate of this bug. ***
Created attachment 101527 [details] An updated ebuild This uses the old beta 15 ebuild as a template, but required quite a few changes to get it working due to a different behavior of the install in beta 20.
Created attachment 106199 [details] gambit-4.0_beta20.ebuild An ebuild for gambit 4.0-beta20, based on previouses. It works around the problem of some locations being hardcoded in binaries, compile and install misc/syntax-case.scm at the right place, enable a new optimisation and honor USEFLAGs.
Brice, when gambit is not installed yet I get: ../gsc/gsc: error while loading shared libraries: libgambc.so: cannot open shared object file: No such file or directory with your ebuild. I think what you want is: pkg_postinst() { einfo "Compiling syntax-case.scm..." gsc-gambit $ROOT/usr/lib/syntax-case.scm } but why do you do that "../gsc/gsc syntax-case.scm" anyway? I don't think forcing -j1 is nice to do. How much memory do you have and what MAKE_OPTS do you have? Also --enable-gcc-opts should be enabled. Maybe there can be a use flag to turn off that and enable -j1 or something for people who have little memory. I also don't think a doc use flag for so few docs is really necessary. What do you think?
Sorry, "../gsc/gsc" should be replaced by "LD_LIBRARY_PATH=../lib/ ../gsc/gsc". I was thinking that building syntax-case could be a good idea since (syntax-case ...) is a requirement of r5rs and so needed for gambit to compile valid scheme code (including mine). The build process with "--enable-gcc-opts" is described in INSTALL.txt as taking "roughly 2 gigabytes". The same file also tell that "with --enable-single-host the build takes roughly 500 megabytes". So I was afraid that -j2 could make the build too slow for most computers, which have less than a 1GB of RAM (so likely much less than 1GB of free RAM). For many users that have multicores CPU (-j3 or more) the build process could even result in a DoS. That being said, I must recognise that a useflag activating "--enable-gcc-opts" is a good idea, even if imho it may be more secure to disable it by default. I have 768MB of RAM, 316MB of free RAM while I'm writing this. MAKEOPTS="-j2" Thanks for your work ^_^
Created attachment 106300 [details] gambit-4.0_beta20.ebuild I realised that I didn't answered everything, and forgot the ebuild. And I just understood that you were talking of installing syntax-case.scm without compiling it. This new ebuild do that. You were also right about doc. Maybe the same apply to examples, I don't really know. Please find attached an ebuild wich fix those problems. (reading my previous comment, I realised that I talked in a very peremptory manner, please excuse me for that (english is not my native language))
Hi Brice, I have some more questions. I was trying to determine how messed up make install is, so I had a look at what einstall spits out. From what I can see it looks like only /usr/doc/gambit-c.{html, pdf,txt} and /usr/syntax-case.scm are in the wrong place. Perhaps gambit.el too. The examples aren't installed at all. Did I miss anything? Why do you remove the makefiles from the examples before installing? Also gsc-script -> gsi is different from what your ebuild does: dosym gsc-gambit /usr/bin/gsc-script If syntax-case.scm is installed and not compiled (as your last ebuild does) then it will get compiled the first time you compile a r5rs program, right? You don't need to immediately attach a new ebuild, unless you feel compelled to ;) I'm more interested in why you wrote it that way. Don't take my ignorance for criticism and I will excuse you for your excellent english :) It looks like high memory usage is not an acceptable reason to replace -j flags because of. Please try compiling with your normal -j2 and tell me how bad it was. One last question, do you use slib on gambit?
I didn't used the install rule of the makefile, because it's target directory gets harcoded in libgambc.so to determine where gambit will look for files (line 257 of ./lib/os_files.c and others). Also, the ebuild do not yet try to build guide (as it is pre-pre-alpha software), but when the next version of gambit will be published, the target will also be hardcoded in guide. So there I considered two options : patch the sourcecode to write right places were appropriate (and taking the risk of missing some); or tell to ./configure were the files will actually be (and writing an install script in the ebuild). I would normaly have choosen the first (to patch). But looking at the ebuild that Paul Berg submit, I told myself that the list of workarounds required to install recent releases use make install was already longer than what would be needed to install gambit using eutils, and much more likely to break. While this time, I thinked to that again, and changed my opinion, because of what you said about slib : it seems to be a really nice thing, the problem being that the ebuild in portage only care about Guile. I think that this could be fixed simply by installing it in a vendor-neutral location (/usr/share/slib seems right if the ebuild do not precompile it), then : if a guile useflag is set, do the symlink trick described in the README, if a gambit useflag is set, add to gambcext.scm... The point is that, following those conventions, gambit libs like "syntax-case" should be instaled to "/usr/share/gambit", so the code would need to be patched anyway (to make it look in /usr/share instead of /usr/lib), and my eutils workaround is useless. But that lead to the question of knowing if syntax-case should be compiled (as only architecture-neutral files fits in "/usr/share"). That file do not get automatically built by gambit, excepted if you run gambit as root, but on can easily copy it in it's project and compile it there... This time, I'll wait for your advices before to write an ebuild, if you don't require it :-P Do you want me to fill a bug about what could be done in slib ? I hadn't realised that there were soooo much work to do for Scheme on Gentoo... Two lasts things : * The makefiles I remove do not works outside of gambit workdir. * I built gambit with -j2, without gcc-opts. Those were the three first lines of top. > top - 17:48:31 up 3:56, 5 users, load average: 2.75, 3.14, 2.11 > Tasks: 101 total, 1 running, 100 sleeping, 0 stopped, 0 zombie > Cpu(s): 1.7% us, 1.3% sy, 13.9% ni, 0.0% id, 82.1% wa, 1.0% hi, 0.0% si > Mem: 743256k total, 736076k used, 7180k free, 1552k buffers > Swap: 1209592k total, 620620k used, 588972k free, 11416k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 2088 root 27 12 480m 329m 2308 D 0.3 45.3 1:15.33 /usr/libexec/gcc/i686-pc-linux-gnu/4.1.1/cc1 -quiet -I../in > 2086 root 27 12 510m 322m 3024 D 14.0 44.4 1:41.07 /usr/libexec/gcc/i686-pc-linux-gnu/4.1.1/cc1 -quiet -I../in > 7588 brice 15 0 142m 6676 3400 S 0.0 0.9 3:47.10 amarokapp Maybe something is wrong in my setup, but I don't think... you don't have the same behaviour ? For me this case seems like the one of kdeenablefinal (disabled by default), but I don't really know what is the gentoo way of dealing with such problems, so I'll trust you ;-)
Created attachment 106981 [details] gambit-4.0_beta20.ebuild Syntax-case gets compiled, but unfortunately the binary is put into /var/tmp/portage/. I've had a short look at "info gambit". Looks like =/usr/lib/ or something like that might work or maybe GAMCOPTS need to be set. Criticism and testing would be much appreciated.
This ebuild look fine for me, I even didn't knew CHECKREQS_MEMORY :-P Just a few things : Are you sure that it is a good idea to build syntax-case.scm in pkg_postinst() ? I hadn't thinked that binary packages were meant to compile things, especially during the install phase. Also, I think that everything should now, but a grep GAMCOPTS returned nothing. Do you really thinks that those makefiles are useful ?
To be more precise, I think that this way of build syntax-case might be better : LD_LIBRARY_PATH+=:lib/ gsc/gsc -c -o misc/syntax-case.o1.c misc/syntax-case.scm # breaks if you change output name ./bin/gsc-cc-o / misc/syntax-case.o1 misc/syntax-case.o1.c -Iinclude/ at least it seems to work-for-me™ in src_compile(), after emake.
GAMBCOPT is what I meant. I'll have to think some more on compiling syntax-case earlier, but I think it would indeed be better. I expect those makefiles in the examples are there for a reason. I'd need a good reason to remove them. What I would like is that if you leave off that -o when compiling some file, that it still gets put into some sane directory, not /var/tmp/portage/. Please concentrate on this first :)
(In reply to comment #12) > GAMBCOPT is what I meant. > I'll have to think some more on compiling syntax-case earlier, but I think it > would indeed be better. Once again, you're right. Using GAMBCOPT is much nicer than my idea on comment #10 (which itself could even be nicer, if hadn't typoed the last line)... I should have tried to RTFM before to hack. > I expect those makefiles in the examples are there for a reason. I'd need a > good reason to remove them. They are there so you can do a « cd examples/pi; make pi.o1 », they reference various parts of the build system and won't works outside of it. But it's true that they don't hurt neither -_^ > What I would like is that if you leave off that -o when compiling some file, > that it still gets put into some sane directory, not /var/tmp/portage/.Please > concentrate on this first :) Having syntax-case at the right place seems easy with GAMCOPT. If you build from inside src_compile() an with « LD_LIBRARY_PATH+=:lib/ GAMBCOPT==. gsc/gsc misc/syntax-case.scm » then syntax-case.o1 will be in ${S}, wich should be fine.
fixed. Thanks Brice and Paul.
Why does beta20 want app-editors/emacs instead of virtual/emacs? Is this deliberate? If not, it is a bug - but hardly worth a whole new bug report if someone will just amend the ebuild :)
virtual/emacs doesn't exist anymore AFAIK
(In reply to comment #16) > virtual/emacs doesn't exist anymore AFAIK > I don't understand why that has any bearing on the matter. In both the emacs and emacs-cvs ebuilds, there is a line: PROVIDE="virtual/emacs virtual/editor" and in each of the 24 ebuilds I have installed which are either app-emacs/* or have some elisp files to install according to the "emacs" USE flag - e.g. gnuplot - there is a DEPEND clause for virtual/emacs. In gnuplot's case, it is: emacs? ( virtual/emacs !app-emacs/gnuplot-mode ) This fine mechanism is clearly still working - if it wasn't, as an emacs-cvs user, I'd be in big trouble!
Okay, I guess I was wrong. Fixed now.
