Find the next camomile build system about camomile

[rgrinberg]

Bsdowl sounds like a decent choice because you're obviously an expert with it. One of the only redeeming qualities of oasis/ocamlbuild is that it's relatively portable on Windows. How does bsdowl fare in this respect?

OMakefile is also a fairly sane and portable makefile system

[seliopou]

The "If it ain't broke don't fix it" philosophy should probably be applied here. The Makefile.in and configure.in look pretty clean and carefully constructed. configure.in is also where the WinGW hacks happen to to maintain windows compatibility. In addition, a lot of what the library does is process Unicode specifications to spit out data files that are then shipped with the distribution. No matter which way you cut it, the Makefile is going to need some custom attention, and this is already written and working.

Regarding portability, autotools is required to build a tarball distribution, but after that there is no build dependency on autotools (as far as I can tell).

[foretspaisibles]

The "If it ain't broke don't fix it" philosophy should probably be applied here.

While I definitely agree, purely handwritten Makefiles on large projects are usually very inflexible when it comes to reorganise code across directories and so on. But let's wait to see the problems before touching this! :)

In case you are still interested in this, today I imported Camomile in the Jane Street repository. Before doing this I converted Camomile to jbuilder to understand properly it's build process. I put the result on my github: https://github.com/diml/Camomile/tree/jbuilder

Some of the jbuild files are a bit verbose, it's because jbuilder is not yet able to generate rules dynamically and doesn't yet support multi-directory libraries properly.

Nevertheless, apart from charmaps/jbuild the jbuild files are pretty straightforward. Camomile builds quite a lot faster as a result: 4s on my machine with -j16. I couldn't build in parallel with the original Makefile.

[yoriyuki]

Thank you. Since I'm not familiar with jbuilder, I can't see how you handled data file generation. I only saw jbuild in charmaps directory. How you handled other data?

There are also jbuild files in the other directories: database, locales and mappings. For each directory, I added an install stanza listing the files to install as well as user rules for generating the various files, such as:

(rule
 ((targets (White_Space.mar White_Space_set.mar))
  (deps    (../unidata/PropList.txt))
  (action  (run ../tools/parse_uniset.exe -filter . White_Space ${<}))))

Currently the rules are listed manually. Some directories, such as charmaps where a bit complicated to handle as the list of targets is dynamic. For now I wrote the jbuild in OCaml, which is a feature allowing you to generate the contents of the jbuild file on the fly with some OCaml code.

[yoriyuki]

I see. It would be worthwhile to move jbuilder from GNU Make, but I want to make the targets in locales also dynamically generated.

How do other guys think?

[rgrinberg]

@diml is there anything left in this effort?

I suppose converting locales/jbuild to OCaml syntax to have them dynamically generated. And once ocaml/dune#35 is finished the main jbuild file can be cleaned.

Otherwise the current version should work well already.

[rgrinberg]

Mind putting up a PR? I'll see if I can put in the finishing touches if you're too busy for this.

Sure: #22

[yoriyuki]

We have moved to jbuilder. Thank you for PR @diml @rgrinberg