OCaml spec file support macros
by Jerry James
Hi all,
I've been experimenting with adding some macros to make OCaml
packaging a bit easier. You can see what I have so far here:
https://src.fedoraproject.org/fork/jjames/rpms/ocaml-srpm-macros/c/9554c8...
With these macros, the main part of a spec file for a package that
builds with dune can be as simple as this:
```
%build
%dune_build
%install
%dune_install
%check
%dune_check
%files -f .ofiles
%doc README.md
%license LICENSE.md
%files devel -f .ofiles-devel
```
Packages that do not use dune to build can still use the %ocaml_files
macro at the end of %install to generate .ofiles and .ofiles-devel
files to pass to %files.
New macros:
- %ocamldir: shorter replacement for %{_libdir}/ocaml
- %odoc_package: inspired by %javadoc_package, everything you need in one
place to declare a package that contains odoc documentation.
- %relink_stublibs: automatically locate any dll*.so files created by
ocamlmklib and relink them with Fedora linker flags
- %_add_release_func: internal macro to add `--release` to flags passed to
%dune_build or %dune_check if neither `--release` nor `-p` has been given.
I should probably rewrite it in lua.
- %dune_build: invoke `dune build` with a standard set of flags, followed by
%relink_stublibs. Arguments can be passed to dune, e.g.,
`%dune_build @install`.
- %dune_check: invoke `dune runtest` with a standard set of flags. Arguments
can be passed to dune, e.g., `%dune_check -p foobar`.
- %ocaml_files: generate .ofiles* files to pass to %files from files installed
in the buildroot. Use of this macro requires python3 to be installed in the
chroot. By default, files are split into a main package (.ofiles) and a
devel package (.ofiles-devel). Use `%ocaml_files -n` to ump all files
together into .ofiles. Use `%ocaml_files -s` to generate files with the
OCaml module name embedded in them; e.g., .ofiles-module1,
.ofiles-module1-devel, .ofiles-module2, .ofiles-module2-devel, etc.
- %dune_install: invoke `dune install` with a standard set of flags, then:
- Remove any .dune-keep markers left over from running odoc
- Remove anything installed into /usr/doc
- Remove all *.ml files that have matching *.mli files installed
- Invoke %ocaml_files, with the same -s or -n options passed to
%dune_install itself
I would appreciate any feedback you can offer. My questions:
1. Is ocaml-srpm-macros the best place for this?
2. Is the python dependency for %ocaml_files / %dune_install okay? I thought
about writing it in lua to avoid the external dependency, but then the
entire %install script has to be written in lua. If the entire %install
script is just %dune_install, then that's okay, but it seems like a
significant barrier otherwise.
3. Can you think of any other macros that would be useful?
4. I wonder if it would be useful to allow overrides for the logic used by
%ocaml_files to split files into the main and devel packages. Perhaps
something like this:
-d file1,file2,...: comma-separated list of files to put in the devel
package, even if they would normally go in the main package
-m file1,file2,...: comma-separated list of files to put in the main
package, even if they would normally go in the devel package
Too bad for you if you want to do this to a file with a comma in its name.
:-) Of course, one can always do surgery on the .ofiles* files after they
are created, so maybe this would be overkill.
I was working on making a bunch of spec files for everyone to look at
when the package notes feature derailed me. Sigh. I'm going to get
that cleaned up first, then I hope to get back to making examples.
Regards,
--
Jerry James
http://www.jamezone.org/
1 year, 10 months
- 4
- 9
New OCaml macros
by Jerry James
Hello OCaml packagers!
There is now a COPR repo showing off what the new OCaml macros can do:
https://copr.fedorainfracloud.org/coprs/jjames/Infer/
Yes, that's the same COPR repo I just mentioned on fedora-devel-list.
I'm interested in feedback. Things to note:
1. I basically did a full review on each package. This has taken a
few months. In the process, I have identified lots of incorrect
License tags and found other ways the spec files could be improved or
simplified. If your OCaml package isn't in the COPR repo, that means
I didn't see anything in the spec file that ought to be changed.
2. I've abandoned the use of odoc to build documentation. Richard
Jones pointed out that odoc has been a big source of dependency loops,
for one thing. For another, we can't really take advantage of odoc's
crosslinking capabilities without doing bootstrap builds for dozens of
packages until we can build odoc, then building everything a second
time to generate the documentation. Finally, the documentation is
generally available online anyway. Does anybody object to discarding
the odoc-generated documentation?
3. I've moved away from using %srcname or %libname macros. As Miro
has been pointing out on fedora-devel-list for some time, those macros
seem to obscure more than they help.
4. If you want to see how all of these OCaml packages are related to
each other, take a look at one of these:
https://jamezone.org/pleasure/software/Fedora/infer.dot
https://jamezone.org/pleasure/software/Fedora/infer.pdf
This graph shows the "build before" order. That is, if there is an
arrow from A to B, then A must be built before B.
Legend:
Black node: package is in Fedora
Green node: package has been submitted for review
Red node: package is not in Fedora
Solid black line: Mandatory build requirement
Dashed black line: Optional build requirement
Solid blue line: Test requirement
Solid green line: Documentation requirement
5. Packages that are no longer used after the changes in the repo are
made. We can retire these unless someone has another need for them:
- ocaml-migrate-parsetree
- ocaml-seq
- ocaml-uuidm
6. Many leaf packages contain useful binaries in their own right, or
are used by non-OCaml parts of Fedora. These are the leaf packages
whose usefulness is unknown to me. If nobody is actively using these,
we can think about retiring them:
- ocaml-ancient
- ocaml-augeas
- ocaml-calendar
- ocaml-camlimages
- ocaml-cil
- ocaml-csv
- ocaml-curl
- ocaml-curses
- ocaml-dbus
- ocaml-expat
- ocaml-facile
- ocaml-gsl
- ocaml-lacaml
- ocaml-mysql
- ocaml-newt
- ocaml-obuild
- ocaml-omake
- ocaml-perl4caml
- ocaml-postgresql
- ocaml-res
- ocaml-SDL, and ocaml-lablgl too
- ocaml-ssl
- ocaml-xmlrpc-light
- ocamlify
- ocamlmod
If this looks good, then I will start making pull requests, starting
from the top of that graph in #4 and work my way downward. Be warned
that some of the proposed changes require coordination between
multiple packages.
Regards,
--
Jerry James
http://www.jamezone.org/
2 years, 2 months
- 2
- 1
Updating OCaml packages
by Jerry James
Hello OCaml packagers,
I am going to update some packages in Rawhide today. Most of the Jane
Street packages had releases of version 0.15.0 in late November, and
we updated them in early December ... except that maybe they weren't
really released. All of the 0.15.0 tags were moved to a later commit
2 weeks ago. I don't know what the story is, but there are code
changes, so I'm going to update them to the current set of 0.15.0
tags.
Other version updates:
- coq 8.15.0
- flocq 3.4.3
- ocaml-gen 1.0
- ocaml-integers 0.6.0
- ocaml-menhir 20220210
- ocaml-mtime 1.4.0
- ocaml-qcheck 0.18.1
- ocaml-stdcompat 18
- ocaml-uutf 1.0.3
- why3 1.4.1
Also, I made a terrible, horrible, no good, very bad mistake with the
last alt-ergo update. I uploaded the tarball for the version with a
problematic license instead of the free version. I'm going to upload
the correct tarball and rebuild.
The following packages need rebuilds due to the above changes:
- frama-c
- gappalib-coq
- ocaml-alcotest
- ocaml-luv
- ocaml-lwt
- ocaml-markup
- ocaml-ppxlib
- ocaml-pyml
- ocaml-sedlex
- ocaml-tyxml
- zenon
I plan to repeat all of these builds for F36 if no problems arise in
Rawhide. If you need to build any of these packages today, please
build into the side tag:
fedpkg build --target=f37-build-side-51187
Thanks,
--
Jerry James
http://www.jamezone.org/
2 years, 2 months
- 1
- 1
- ← Newer
- 1
- Older →