From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 59BC47F720 for ; Sun, 13 Apr 2014 11:21:47 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of adrien@notk.org) identity=pra; client-ip=91.121.71.147; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="adrien@notk.org"; x-sender="adrien@notk.org"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of adrien@notk.org designates 91.121.71.147 as permitted sender) identity=mailfrom; client-ip=91.121.71.147; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="adrien@notk.org"; x-sender="adrien@notk.org"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@nautica.notk.org) identity=helo; client-ip=91.121.71.147; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="adrien@notk.org"; x-sender="postmaster@nautica.notk.org"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioFAJFWSlNbeUeT/2dsb2JhbABZgwaDUFLAHYEZFnSCJQEBAQMBIw8BRgULCxgCAgUTDgICDwUYHQETiAcMqBWiHxeBKY1FB4JvNYEUBJhgAZJDgzM7 X-IPAS-Result: AioFAJFWSlNbeUeT/2dsb2JhbABZgwaDUFLAHYEZFnSCJQEBAQMBIw8BRgULCxgCAgUTDgICDwUYHQETiAcMqBWiHxeBKY1FB4JvNYEUBJhgAZJDgzM7 X-IronPort-AV: E=Sophos;i="4.97,850,1389740400"; d="scan'208";a="56887590" Received: from nautica.notk.org ([91.121.71.147]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/ADH-AES256-SHA; 13 Apr 2014 11:21:46 +0200 Received: by nautica.notk.org (Postfix, from userid 1003) id E8480C01D; Sun, 13 Apr 2014 11:21:44 +0200 (CEST) Date: Sun, 13 Apr 2014 11:21:44 +0200 From: Adrien Nader To: Daniel =?utf-8?Q?B=C3=BCnzli?= Cc: "caml-list@inria.fr" Message-ID: <20140413092144.GA1838@notk.org> References: <9636C678CAA541CCB505CE8771722A68@erratique.ch> <063FC564F6B44EA5AB1CF1D5589996D0@erratique.ch> <20140412073949.GA31995@notk.org> <20140412074401.GA803@notk.org> <20140412114145.GA18285@notk.org> <74C2E1F54AA349E6899E909804979B72@erratique.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <74C2E1F54AA349E6899E909804979B72@erratique.ch> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [Caml-list] OCaml script on windows (was Re: [ANN] React 1.0.0) 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