Hi, This ebuild will install the source version of mlton-20041109. Mlton is an optimizing SML compiler. The 20041109 version handles the mlb extension to sml.
Created attachment 71289 [details] mlton ebuild file This ebuild is dependent of mlton-bin-20041109 submitted in bug 110231
Thanks a lot Carsten. I confirming that the new ebuild works for me on x86 stable, when bootstrapping with mlton version that is currently in portage 20040227 installed from the non-binary ebuild. I have not tried bootstrapping with the binary version. This "new" version has been released a year ago by upstream (can be considered fairly stable).
(In reply to comment #1) > This ebuild is dependent of mlton-bin-20041109 submitted in bug 110231 It is not strictly dependent. As you see in my comment, it can be compiled having an older mlton-bin installation. What slightly worries me is the stric dependency on mlton-bin (at least this is how I understand the ebuild). In fact it should be just as happy if there is a previous version of nonbinary mlton in portage.
One more problem. Mysteriously the old man page survived the emerge of the new ebuild at /usr/share/man/man1/mlton.1.gz while the new one is /usr/man/man1/mlton.1.gz. This might be an inconsistency between the binary and nonbinary mlton ebuilds putting man pages in different places. I do not exactly know where the bug is then. The result is that the old man page is default, which may be fairly misleading for an accidental reader.
MLton 20070826 is out
*** Bug 110231 has been marked as a duplicate of this bug. ***
Created attachment 135587 [details] mlton-bin-20070826.ebuild I modified the ebuild found in Portage to install the latest binary version.
Created attachment 135594 [details] mlton-20070826.ebuild modified version from portage tree to install the latest release
Created attachment 135683 [details, diff] upgrade-basis-20070826.patch
Created attachment 135685 [details, diff] mlton-bin-20070826.patch
Created attachment 135686 [details, diff] makefile-mlyacc-20070826.patch
Created attachment 135688 [details, diff] makefile-mlton-20070826.patch
Created attachment 135690 [details, diff] makefile-mlprof-20070826.patch
Created attachment 135692 [details, diff] makefile-mlnlffigen-20070826.patch
Created attachment 135694 [details, diff] makefile-mllex-20070826.patch
Created attachment 135695 [details, diff] makefile-front-end-20070826.patch
Created attachment 135697 [details, diff] makefile-benchmark-20070826.patch
Created attachment 135698 [details] mlton-20070826.ebuild This ebuild combines the binary and source versions to avoid collisions. USEes "binary" like ghc does.
Known issues: - need to change one of the patches dynamically in ebuild - maybe patches can be make more "universal" for reuseability with future releases - two QA notices (stacks and prestripped binaries) - USE="doc" and USE="binary doc" don't install an equal number of files (2703 files when compiled, and 2356 when installed from binary) - needs ~2.?GB of memory (ram+swap) to compile on amd64, therefore it should abort if less is available (which it doesnt atm) and it should - warn about excessive memory usage - still some errors about missing files during src_compile, but I guess they're harmless (For now, fixing them is beyond my interest.)
You could use some sed instead of all those patches ;)
Created attachment 135758 [details] mlton-20070826.ebuild What about this simple ebuild? Please test it.
(In reply to comment #21) > Created an attachment (id=135758) [edit] > mlton-20070826.ebuild > > What about this simple ebuild? Please test it. > Shoudnt things like die "emerge with binary use flag first" be avoided when possible? It is some kind of interactivity which is the cause emerge exists: avoid manual actions, once the desired result is verbalized (i.e., emerge foo). At least I strongly dislike those ebuilds :-)
(In reply to comment #20) > You could use some sed instead of all those patches ;) > I dont see how (otherwise I would have done so), if you know it, just do it so we'll see what you mean.
(In reply to comment #22) > (In reply to comment #21) > > Created an attachment (id=135758) [edit] > > mlton-20070826.ebuild > > > > What about this simple ebuild? Please test it. > > > Shoudnt things like > die "emerge with binary use flag first" > be avoided when possible? It is some kind of interactivity which is the cause > emerge exists: avoid manual actions, once the desired result is verbalized > (i.e., emerge foo). > At least I strongly dislike those ebuilds :-) > A quick grep "first" -R /usr/portage|grep emerge showed that very few ebuilds seem to do the like it, and I guess those are cases without a workaround.
(In reply to comment #24) > > Shoudnt things like > > die "emerge with binary use flag first" > > be avoided when possible? It is some kind of interactivity which is the > > cause emerge exists: avoid manual actions, once the desired result is > > verbalized (i.e., emerge foo). > > At least I strongly dislike those ebuilds :-) > A quick > grep "first" -R /usr/portage|grep emerge > showed that very few ebuilds seem to do the like it, and I guess those are > cases without a workaround. Only ebuilds for compilers that need to bootstrap are really interesting to compare for this particular issue. The way I set it up you don't have to download a binary each time you bump mlton, you just use your existing mlton (or even smlnj), but you may still choose to do so using the bin use-flag. So it's more flexible. Perhaps we could change it so that the first time instead of dying it downloads a binary and compiles itself with that. What do you think?
> you just use your existing mlton might raise problems if it's a rather old version, therefore one needs to test of all versions in portage are actually able to compile the one in question > (or even smlnj) But not with the current ebuild or am I missing something?! > Perhaps we could change it so that the first time instead > of dying it downloads a binary and compiles itself with that. What do you > think? Well, that would mean you need to maintain all the patches (or whatever equivalent someone comes up with) I made - although it would be a cool thing of course. That's something for the maintainer to decide.
i tested marijn's ebuild, and works fine on amd64... i used the binary useflag at first, and then tried to compile mlton from source,but it was needed too much ram and time... maybe, i'll test it on a machine with more ram, and give some feedback...
just compiled -binary -doc on amd64 successfully. it also produces correct executables (it correctly compiled es4). doc requires latex-base in order to compile. it dies with make -C "mllex" docs make[1]: Entering directory `/tmp/portage/dev-lang/mlton-20070826/work/mlton-20070826/mllex' latex lexgen.tex make[1]: latex: Command not found as is to be expected
Thanks for testing, fixed.
