Bug 110233 - MLton 20070826 is out
|
Bug#:
110233
|
Product: Gentoo Linux
|
Version: unspecified
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: enhancement
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: ml@gentoo.org
|
Reported By: varming@itu.dk
|
|
Component: Ebuilds
|
|
|
URL:
http://mlton.org/
|
|
Summary: MLton 20070826 is out
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2005-10-23 08:50 0000
|
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.
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.
*** Bug 110231 has been marked as a duplicate of this bug. ***
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 ;)
(In reply to comment #21)
> Created an attachment (id=135758) [edit] [details]
> 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] [details]
> > 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.
