Switch to jbuilder, prepare to release 1.1.0 #7
Conversation
Signed-off-by: David Scott <dave@recoil.org>
Signed-off-by: David Scott <dave@recoil.org>
Signed-off-by: David Scott <dave@recoil.org>
|
I've a couple of questions:
|
|
Beta10 of jbuilder (the next one) is due to have an Isco target |
|
Sorry, an "odoc" target :-) |
mirage-net.version
Outdated
| @@ -0,0 +1 @@ | |||
| 1.1.0 | |||
There was a problem hiding this comment.
this is not needed with beta9 which adds a new jbuilder subst CLI option to do exactly the same watermarking as topkg does.
There was a problem hiding this comment.
(so you can continue to use %%VERSION%% in various places)
src/jbuild
Outdated
| (public_name mirage-net) | ||
| (libraries (bytes result mirage-device)) | ||
| (modules (Mirage_net)) | ||
| (flags (:standard -w "A-4-41-44" -warn-error "+1..49" -safe-string)) |
There was a problem hiding this comment.
I'm not sure about adding warning errors to the build runes run which will be run after the release. I thing it's better to use topkg build --dev while doing development (which has a sane set of warning/error options).
There was a problem hiding this comment.
In this case I coped the contents of the _tags file: true: warn_error(+1..49), warn(A-4-41-44). I'm not very familiar with the semantics of this though. Is it not safe to use a specified list "1,2,3,...,49" since they're already defined and won't be redefined in future versions of the compiler? I thought the main problem was with the equivalent of -Wall which includes future yet-to-be-defined errors.
Wrt to topkg could you explain a bit more? I see this:
$ topkg build --dev
topkg: unknown option `--dev', did you mean `-d' ?
Usage: topkg build [OPTION]... [BUILD_CONF]...
Try `topkg build --help' or `topkg --help' for more information.
(I was never a topkg expert). Is your suggestion to use topkg and jbuilder together? Could you outline what the build and release workflow would look like? Thanks!
|
@hannesm: the "ml -> mli" renaming is due to ocaml/dune#9 I have no strong opinion on whether we should keep the mli or have a ml file, but pure mlis don't work with module aliases which seems a good argument to me to not use them (until this is fixed in the compiler). |
|
On 19/05/2017 20:03, Thomas Gazagnaire wrote:
I have no strong opinion on whether we should keep the mli or have a ml file, but pure mlis don't work with module aliases which seems a good argument to me to not use them (until this is fixed in the compiler).
Does odoc use .ml for generating documentation? I'm a bit worried to
lose automatic generation of documentation.
|
The command `jbuilder subst` should be used to perform the substitution before creating the release tarball. Signed-off-by: David Scott <dave@recoil.org>
The PACKAGE is set to mirage-net-lwt which depends on mirage-net (also from this repository) which we PIN. Signed-off-by: David Scott <dave@recoil.org>
This trick is copied from https://github.com/ocaml-doc/odoc/blob/master/odoc.opam Signed-off-by: David Scott <dave@recoil.org>
This copies the configuration from https://github.com/ocaml-doc/odoc/blob/master/pkg/pkg.ml It requires the new `topkg-jbuilder` package: https://github.com/ocaml/opam-repository/pull/9231/files Signed-off-by: David Scott <dave@recoil.org>
|
I've pushed a few more changes for review (can squash them later)
BTW have we documented the ideal / best-practice package release workflow anywhere? I've still been relying on the github "release" button which I realise isn't ideal, and I haven't got a great way to automatically update API docs etc. |
|
Sorry I meant 'jbuilder build --dev'
… On 20 May 2017, at 01:27, Dave Scott ***@***.***> wrote:
@djs55 commented on this pull request.
In src/jbuild:
> @@ -0,0 +1,17 @@
+(library
+ ((name mirage_net)
+ (public_name mirage-net)
+ (libraries (bytes result mirage-device))
+ (modules (Mirage_net))
+ (flags (:standard -w "A-4-41-44" -warn-error "+1..49" -safe-string))
In this case I coped the contents of the _tags file: true: warn_error(+1..49), warn(A-4-41-44). I'm not very familiar with the semantics of this though. Is it not safe to use a specified list "1,2,3,...,49" since they're already defined and won't be redefined in future versions of the compiler? I thought the main problem was with the equivalent of -Wall which includes future yet-to-be-defined errors.
Wrt to topkg could you explain a bit more? I see this:
$ topkg build --dev
topkg: unknown option `--dev', did you mean `-d' ?
Usage: topkg build [OPTION]... [BUILD_CONF]...
Try `topkg build --help' or `topkg --help' for more information.
(I was never a topkg expert). Is your suggestion to use topkg and jbuilder together? Could you outline what the build and release workflow would look like? Thanks!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
With topkg-jbuilder integration, 'topkg tag && topkg bistro' almost works: 'topkg doc' (used to generate the docs) will fail but @diml is working on this.
So I just used to follow what 'topkg help release' says but I'm replacing the "publish" part by 'topkg publish distrib" -- that will not try to build and publish the docs.
… On 20 May 2017, at 01:55, Dave Scott ***@***.***> wrote:
I've pushed a few more changes for review (can squash them later)
.version files now contain %%VERSION%%. Note that jbuilder understands several ways to find the version number to put in the generated META file -- it can also take the version from the opam file. My understanding is that opam-repository repository opam files are not supposed to contain the version so I opted for not putting the version in here either, so that I could manually diff and cp the opam files. I'm not sure what opam-publish does or prefers.
I copied a trick from odoc itself: the build rules now perform jbuilder subst if the package is {pinned}
I also copied the odoc package's pkg/pkg.ml file which references the new package topkg-jbuilder. After I installed this (opam pin add topkg-jbuilder git://github.com/diml/topkg-jbuilder.git since ocaml/opam-repository#9231 is not yet merged) I could then run topkg build
I verified that odoc compile --help says Input file (either .cmti or .cmt). I did a odoc compile and then odoc html to check that stuff wa output -- so I think we're good with either the .ml or the mli file
BTW have we documented the ideal / best-practice package release workflow anywhere? I've still been relying on the github "release" button which I realise isn't ideal, and I haven't got a great way to automatically update API docs etc.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
Signed-off-by: David Scott <dave@recoil.org>
| @@ -0,0 +1 @@ | |||
| %%VERSION%% | |||
There was a problem hiding this comment.
I am still not totally sure why we need this file :-)
|
I need to check what's in the META file after installing the output of
"topkg distrib". It might also be useful for "opam pin" if there's a
"jbuilder subst {pinned}" in the opam file? I'm happy to remove it if
everything has the right version without it :)
…On 29 May 2017 1:50 pm, "Thomas Gazagnaire" ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In mirage-net-lwt.version
<#7 (comment)>:
> @@ -0,0 +1 @@
+%%VERSION%%
I am still not totally sure why we need this file :-)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#7 (review)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAMHuqoacchcFJ4oPVKmfXp2odML1I-Wks5r-r77gaJpZM4NgwS6>
.
|
|
oops i am clashing with #8 |
See discussion on mirage#7 Signed-off-by: David Scott <dave@recoil.org>
No description provided.