Bug 194420 - Review Request: mlton, an optimizing compiler for Standard ML
Review Request: mlton, an optimizing compiler for Standard ML
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Gérard Milmeister
Fedora Package Reviews List
:
Depends On:
Blocks: FE-ACCEPT
  Show dependency treegraph
 
Reported: 2006-06-07 18:29 EDT by Adam Goode
Modified: 2014-07-10 09:03 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-07-11 08:44:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
limburgher: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Adam Goode 2006-06-07 18:29:09 EDT
Spec URL: http://www.spicenitz.org/fedora/mlton.spec
SRPM URL: http://www.spicenitz.org/fedora/mlton-20051202-1.src.rpm
Description:  MLton is a whole-program optimizing compiler for Standard ML.
MLton generates standalone executables with excellent runtime performance,
is SML 97 compliant, and has a complete basis library.  MLton has
source-level profiling, a fast C FFI, an interface to the GNU
multiprecision library, and lots of useful libraries.
Comment 1 Gérard Milmeister 2006-06-08 16:38:51 EDT
How are we going to do the bootstrapping?

BTW, here is my spec file, it might contain something of interest:
http://math.ifi.unizh.ch/fedora/spec/mlton.spec
Comment 2 Adam Goode 2006-06-08 19:37:11 EDT
I have a new version of the "source" package. It contains binary
versions of MLton for ppc and i386 in order to bootstrap the system.
Then the bootstrapping can be removed and replaced with
BuildRequires: mlton.

http://www.spicenitz.org/fedora/mlton-20051202-2.src.rpm
http://www.spicenitz.org/fedora/mlton.spec


For reference, see:
http://www.redhat.com/archives/fedora-extras-list/2006-June/msg00301.html
Comment 3 Gérard Milmeister 2006-06-15 11:07:17 EDT
I try to recall what I wrote in the comment that disappeared.
1. Possible convert mllex.ps.gz and mlyacc.ps.gz to .pdf using ps2pdf.
   This would make the doc more consistent. The pdf are not much larger
   than ps.gz.
2. /usr/lib/mlton/sml/ckit-lib/regression should probably removed
3. There are several files in subdirectories of /usr/lib/mlton/sml
   that properly belong in the doc.
   For example the README*, BUGS and doc in /usr/lib/mlton/sml/ckit-lib
   could be moved to %{_docdir}/%{name}-version}/ckit-lib
Comment 4 Jason Tibbitts 2006-06-15 13:45:45 EDT
Here's the exact text of Gerard's previous comment:

------- Additional Comments From gemi@bluewin.ch  2006-06-10 05:20 EST -------
mlton compiles fine in mock/i386. I think we should get someone
to test it on ppc. I propose you ask on fedora-extras-list.
There are lot of these annoying devel-file-in-non-devel-package
warning from rpmlint which can be ignored. Other warnings:

W: mlton incoherent-version-in-changelog 20051202-1 20051202-2
E: mlton zero-length /usr/lib/mlton/sml/ckit-lib/regression/output/t6.c
  The regression directory can probably be removed.
  Maybe there are other things in /usr/lib/mlton that are of no use and can be
  safely removed.

The examples compile fine, so I assume the build was correct.
In the doc there are .pdf and .ps.gz files. Maybe one should convert
the .ps.gz to pdf using ps2pdf. That would be more consistent and the
.pdf files are not much larger than the ps.gz files.
Comment 5 Adam Goode 2006-06-20 20:56:59 EDT
I have created a new version:
http://www.spicenitz.org/fedora/mlton-20051202-3.src.rpm
http://www.spicenitz.org/fedora/mlton.spec

Changes:
Create PDF documentation for mlyacc and mllex, by patching the 
makefile to use pdflatex.
Move ckit-lib/doc and smlnj-lib/Doc to %{_docdir}.
Remove regression files from ckit.

I did not move the various documentation files sprinkled about 
lib/sml/* (like README, etc) because the libraries in there are
basically MLton-modified third-party packages, and the files
often refer to the actual directory it's in (by saying things
like "the files in this directory are ..."). I could move the
files, but I'm not sure people would expect that.

Also, I do have a PPC machine here, and have been testing all
my work with it.
Comment 6 Gérard Milmeister 2006-06-21 02:59:18 EDT
I get the following now when building in mock:
Massaging HTML.
/builddir/build/BUILD/mlton-20051202/bin/msed: line 13: which: command not found

"BuildRequires: which" solves this.
Comment 7 Paul Howarth 2006-06-21 07:18:21 EDT
(In reply to comment #6)
> I get the following now when building in mock:
> Massaging HTML.
> /builddir/build/BUILD/mlton-20051202/bin/msed: line 13: which: command not found
> 
> "BuildRequires: which" solves this.

So would adding "which" to your mock buildroot, since "which" was recently added
to the buildreq "Exceptions" list of the packaging guidelines.

If I was the packager, I'd add the buildreq to the spec though; it wouldn't have
been added to the Exceptions list if it had been up to me since it's not an
obvious requirement for package building.
Comment 8 Gérard Milmeister 2006-06-21 13:33:07 EDT
(In reply to comment #7)
> So would adding "which" to your mock buildroot, since "which" was recently added
> to the buildreq "Exceptions" list of the packaging guidelines.
Yes, the latest update of mock includes which.

> If I was the packager, I'd add the buildreq to the spec though; it wouldn't have
> been added to the Exceptions list if it had been up to me since it's not an
> obvious requirement for package building.
It is safer to add the BR for which.

There is one last issue to handle.
There are some licenses in the license directory. Is it certain all
of them can be subsumed under the BSD license?
Comment 9 Adam Goode 2006-06-21 14:52:38 EDT
The license/README file shows that all the licenses are BSD-style
except for one which is MIT-style. (They mention libgmp as LGPL, but
that is not included as part of this package, only as a dependency.)

So with all the licenses being BSD- or MIT-style, does that count
as BSD-style?


Also, I will add "which" to BuildRequires, but is it really necessary?
Comment 10 Gérard Milmeister 2006-06-21 15:22:30 EDT
(In reply to comment #9)
> So with all the licenses being BSD- or MIT-style, does that count
> as BSD-style?
I am no expert on licensing, maybe we should ask on the fedora-extras list
to make sure.
> 
> Also, I will add "which" to BuildRequires, but is it really necessary?
No, it is not necessary.

Comment 11 Adam Goode 2006-06-21 16:06:08 EDT
Ok, new version:

http://www.spicenitz.org/fedora/mlton-20051202-4.src.rpm
http://www.spicenitz.org/fedora/mlton.spec

I've added "which" and changed License to be "BSD style and MIT".
Comment 12 Gérard Milmeister 2006-06-21 18:48:50 EDT
The generated debuginfo package is empty. There is probably no sense
to try to generate debug information for the little runtime code in C
there is, so disable it altogether using '%define debug_package %{nil}'.
Comment 13 Adam Goode 2006-06-22 00:14:19 EDT
New version:

http://www.spicenitz.org/fedora/mlton-20051202-5.src.rpm
http://www.spicenitz.org/fedora/mlton.spec

Debuginfo not generated.
Comment 14 Ville Skyttä 2006-06-22 02:29:32 EDT
Disagreement with comment 12.
Comment 15 Adam Goode 2006-06-22 10:01:59 EDT
Shall I see about enabling debug info then? A little 
more makefile hacking won't hurt at this point.
Comment 16 Adam Goode 2006-06-24 22:40:48 EDT
New version:

http://www.spicenitz.org/fedora/mlton-20051202-6.src.rpm
http://www.spicenitz.org/fedora/mlton.spec

I have enabled debuginfo generation.
Comment 17 Gérard Milmeister 2006-07-01 03:20:14 EDT
There is now substantial debuginfo.
The built takes over 700M of memory and generates a lot of thrashing.
This used to happen with some previous version, but seemed to have
to improved since. Can you confirm this?

rpmlint on the src rpm:
W: mlton macro-in-%changelog _docdir
simply use %%{_docdir} instead of %{_docdir}

W: mlton mixed-use-of-spaces-and-tabs
Don't know where this occurs.
Comment 18 Adam Goode 2006-07-01 23:30:38 EDT
Yes, MLton is infamous for using a large amount of core. Upstream is aware of
the problem and tries to keep it under control, but since MLton is a
whole-program compiler (and has core assumptions that rely on this), a lot of
memory use is expected when compiling something complex (like MLton itself).

New package:

http://www.spicenitz.org/fedora/mlton-20051202-7.src.rpm
http://www.spicenitz.org/fedora/mlton.spec

Fixes the 2 rpmlint problems above.
Comment 19 Gérard Milmeister 2006-07-09 06:58:51 EDT
There are no blockers as far as I can see.
I could only test on i386, so I can't comment
on the other platforms.

APPROVED
Comment 20 Adam Goode 2009-09-08 17:01:26 EDT
Package Change Request
======================
Package Name: mlton
New Branches: EL-5
Owners: agoode rjones
Comment 21 Kevin Fenzi 2009-09-09 12:22:31 EDT
cvs done.
Comment 22 Adam Goode 2014-07-09 21:11:19 EDT
Package Change Request
======================
Package Name: mlton
New Branches: epel7
Owners: agoode rjones
Comment 23 Jon Ciesla 2014-07-10 09:03:02 EDT
Git done (by process-git-requests).

Note You need to log in before you can comment on or make changes to this bug.