Re: [Caml-list] OCaml script on windows (was Re: [ANN] React 1.0.0)

[Adrien Nader <adrien@notk.org>]

On Sat, Apr 12, 2014, Daniel Bünzli wrote:
> 
> 
> Le samedi, 12 avril 2014 à 13:41, Adrien Nader a écrit :
> 
> > In a few words, today you can expect a posix shell but this isn't very
> > future-proof. However I'd probably not change much the current build
> > system: process management in OCaml is more work than in shell and a
> > arewrite would take time for little benefit, all while the environment
> > is evolving rapidly.
> 
> Future-proof is what interests me. In my case the package build script needs a single ocamlbuild invocation and write one (.install) file so that wouldn't be atrocious to manage, there's no cp, mv, install etc, I leave that to my friend opam-installer. Actually I'm interested in rewriting these script in .ml for readability, abstraction and maybe having a more readable command line interface through a handful of combinators and the Arg module. So if these things become ml scripts the cross platform way of invoking them would then just become:  
> 
>     ocaml pkg/build
> 
> rather than just
> 
>     pkg/build
> 
> that would take care of the fact that windows wouldn't understand #!/usr/bin/env ocaml ?

Point taken for the rewrite to OCaml.

The addition of functionalities doesn't sound like a very good idea to
me however. With all the
these-build-systems-suck-I-ll-just-write-my-own-build-system that I've
seen (mostly with autotools), I don't believe this is a good idea. A
comprehensive build system is a full project on its own and takes time
to get ready.

An example is probably x264: some disdain for autotools and lots of
hubris. I think that several years ago their "configure" script was
around 200 lines; nowadays it's 1300 lines. And there's some Makefile
and some more other stuff. And it is heavily biased towards GNU and
Linux.
And zlib is another example. But this one is so ridiculous it isn't even
funny.

All the build system I've seen that started as part of another project
have either gotten larger than what they wanted to replace while still
not matching functionalities or have gotten abandoned, probably after a
painful desperation and madness phase for their maintainers.

tl;dr: if you roll your own build system as part of an existing project,
don't try to be comprehensive or you'll most likely do worse than what
you were trying to avoid. Keep it simple so that at least it's easy for
anyone to learn and debug.

As for the original question, "ocaml foo" should replace the shebang.

> P.S. Is there any tutorial/instructions that shows us how ocaml development occurs/should be done on windows ? Packager instructions about dos and don'ts would be helpful too.  

I'm not aware of such a resource.

From my point of view, most rules are not specific to Windows: use
ocamlfind, handle DESTDIR one way or another, try to not hardcode paths.

Now, the Windows specifics.

The first thing to be aware on Windows is fragmentation. (that was just
too tempting to mention after hearing so much about the distribution
fragmentation on Linux :) ).

Anyway. Constant: your code will be running against the Win32 API and
use Microsoft's libraries (msvcrt*.dll for instance).
Variables: compilers and environments in which they run.

C compilers can be Visual Studio (MSVC), GCC native (i.e. mingw*), GCC
Cygwin (I'll leave this one out for the obvious reason), LLVM, probably
still some Borland and others.

Environments can be: native windows, msys, cygwin, Interix/SFU/SUA (now
dead).
- native windows doesn't need an additional description.
- cygwin provides you with a mostly POSIX environment.
- msys (a fork of Cygwin with some things like automatic translation of
  command-line arguments or environment variables like "/opt/foo" to
  "C:\\Msys\\opt\\foo" when an msys application starts a native windows
  application) provides you with something that looks like a POSIX
  environment (the goal was to run ./configure, no more, no less).

Keep in mind that running tools in Cygwin and building for native
windows is perfectly valid and is actually encouraged for OCaml. It is
simply cross-compilation with the special case that the system which
compiles can also run the binaries it has compiled.

Chose the tools and environments you want to support. Most constraints
should then be obvious.

Worth mentionning, CMake and LLVM have chosen to go the MSVC-route
mostly.
By doing so, cmake has also chosen to not rely on pkg-config and to
instead use heuristics to locate libraries; it's not something I agree
with but it's a valid choice.
As for LLVM, they've chosen to basically create "msvclang", i.e. a
compiler which masquerades as cl.exe (msvc's command-line compiler) and
mimics its command-line interface and error messages.

I hope this was clear enough and not too unreadable.

-- 
Adrien Nader