mjolnir, after Mjölnir, the hammer of Thor.
“…whatsoever might be before him, and the hammer would not fail; and if he threw it at anything, it would never miss…” (Prose Edda)
The name is almost certain to complete from “mj” on a Unix-like system.
Another theme we could explore is “butler”. It’s kind of the job of jbuilder: we give jbuilder high level information and orders and it takes care of everything. And I think think it works well as a command line tool:
$ butler build $ butler install $ butler deploy ...
I guess this description is true for a lot of tool though. One idea would be just
db for Development Butler.
An executable named “db” on unix systems ? You really want sysadmins to commit suicide, don’t you ?
(I remember a very general purpose tool called butler, but I don’t remember where)
Do not name a Unix executable “db”…
jeeves or (alfred / pennyworth) would also be a good name with the butler theme.
db is a bad idea indeed.
While I was looking for other ideas, I found this http://www.pitt.edu/~dash/mbuilder.html and in particular the story of the builder Zi. It’s about a dwarf who constructs a church really fast. The ending is not great but otherwise that would be a nice short name
It’s now settled: Jbuilder will be renamed Dune.
Thanks to everyone for helping in finding a new name for Jbuilder! I personally loved the dune books and I’m looking forward to this rename, I think it’s a great choice for Jbuilder.
We’ll start the renaming work at the beginning of next year, you can follow the advancement on this ticket. Dune will be the first non-beta release of the project.
Jbuilder has gone a long way since it’s initial alpha release in December 2016, and I hope Dune will continue to grow and help more developers in 2018.
Jbuilder has evolved from a domain specific industrial tool into a standard build system for the community. There are now 456 packages in opam using Jbuilder from 310 different repositories, and the team has grown with 3 new active developpers.
We are ending this year with exciting work such as cross compilation, with already lots of packages in the
opam-cross-windows repsository successfully using jbuilder to cross compile.
2018 will bring more good news, with in particular the addition of the plugin system which is starting to flesh out nicely. We will also move Dune from the janestreet github organization to a community one.
I thank everyone who contributed to jbuilder by submitting pull requests, reporting issues, participating in design discussions, organizing brainstorming sessions and just using it in their projects. A special thank to @rgrinberg who joined the project early this year and has enormously contributed to it.
IMHO, it would be nice to add the success & failures of cross compilation to obi.
Definitely. We’re getting the basics stabilised first (to make it run unattended), and then will be adding cross-compilation (and native Windows compilation) to the cluster results.
Seriously, a great big thank you to all the jbuilder maintainers. This tool is fricken awesome.
Is there a plan for what the jbuild file will be called? I was thinking maybe “Dunefile” was a good idea (or maybe simply “Dune”?)
Go all in on Dune; melange.
Come on, call it
or with less nerd-cred, something with sand? i like
_sand or the file extension
.sand . it has a simple obvious connection and it sounds nice.
When is the new
dune package going to be on opam? And how long is
jbuilder going to stay (for compatibility)? I’d like to make new releases of libs that I migrated to jbuilder, but I’d rather wait and use
As the original author of the opam-cross repositories, I want to thank the Dune authors and maintainers, and especially @rgrinberg, for excellent work on cross-compilation. Admittedly, I had some initial reservations, but the result has exceeded all of my expectations both in its quality and in how rapidly it was implemented. This is positively one of the best cross-compilation experiences in any of the language ecosystems I take part in.
Related: here is how to safely rename a package in opam:
It’s probably a good time to start thinking about shifting some of the cross repos over to the ocaml/ github org, once our Windows CI kicks into shape in early 2018. We have the machines now, but not the automation just yet…
Sure, I will provide assistance with that.