Bugzilla Bug 110233

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 an attachment (id=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 an attachment (id=135587) [details]
mlton-bin-20070826.ebuild

I modified the ebuild found in Portage to install the latest binary version.

Created an attachment (id=135594) [details]
mlton-20070826.ebuild

modified version from portage tree to install the latest release

Created an attachment (id=135683) [details]
upgrade-basis-20070826.patch

Created an attachment (id=135685) [details]
mlton-bin-20070826.patch

Created an attachment (id=135686) [details]
makefile-mlyacc-20070826.patch

Created an attachment (id=135688) [details]
makefile-mlton-20070826.patch

Created an attachment (id=135690) [details]
makefile-mlprof-20070826.patch

Created an attachment (id=135692) [details]
makefile-mlnlffigen-20070826.patch

Created an attachment (id=135694) [details]
makefile-mllex-20070826.patch

Created an attachment (id=135695) [details]
makefile-front-end-20070826.patch

Created an attachment (id=135697) [details]
makefile-benchmark-20070826.patch

Created an attachment (id=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 an attachment (id=135758) [details]
mlton-20070826.ebuild

What about this simple ebuild? Please test it.

(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.