Bug 194420
Summary: | Review Request: mlton, an optimizing compiler for Standard ML | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Adam Goode <adam> |
Component: | Package Review | Assignee: | Gérard Milmeister <gemi> |
Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Package Reviews List <fedora-package-review> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | gemi |
Target Milestone: | --- | Flags: | gwync:
fedora-cvs+
|
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2006-07-11 12:44:05 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 163779 |
Description
Adam Goode
2006-06-07 22:29:09 UTC
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 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 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 Here's the exact text of Gerard's previous comment: ------- Additional Comments From gemi 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. 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. 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. (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. (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? 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? (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. 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". 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}'. New version: http://www.spicenitz.org/fedora/mlton-20051202-5.src.rpm http://www.spicenitz.org/fedora/mlton.spec Debuginfo not generated. Disagreement with comment 12. Shall I see about enabling debug info then? A little more makefile hacking won't hurt at this point. New version: http://www.spicenitz.org/fedora/mlton-20051202-6.src.rpm http://www.spicenitz.org/fedora/mlton.spec I have enabled debuginfo generation. 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. 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. 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 Package Change Request ====================== Package Name: mlton New Branches: EL-5 Owners: agoode rjones cvs done. Package Change Request ====================== Package Name: mlton New Branches: epel7 Owners: agoode rjones Git done (by process-git-requests). |