<p dir="ltr"><br>
</p>
<p dir="ltr"></p>
<p dir="ltr">On Tue, Nov 4, 2014, 08:42 Louis Gesbert <<a href="mailto:louis.gesbert@ocamlpro.com">louis.gesbert@ocamlpro.com</a>> wrote:</p>
<blockquote><p dir="ltr">Thanks for these comments !</p>
<p dir="ltr">* Rewrite the parallel command engine</p>
<p dir="ltr">This is well underway, I've got a working prototype with limited backends at the moment.<br>
I'm not relying on fork anymore, but we'll still need some windows way of implementing `Unix.waitpid 0`; and to add OS switches to the build system.</p>
<p dir="ltr">* Native system manipulation</p>
<p dir="ltr">I agree on re-coding cp, mv etc.; here is also a possible idea, it may be worth checking if it's practical: make sure we may work if limited to busybox, and include some Windows version of busybox in the Windows distribution.</p>
</blockquote>
<p dir="ltr"><br></p>
<p dir="ltr">I am about to release a new version of ocaml-fileutils that have better implementation of cp, mv than the previous version. You may consider using. POSIX implementation of those command require some work.</p>
<blockquote><p dir="ltr"></p>
<p dir="ltr">* Test & fix on Windows<br>
> "Cygwin, then, maybe, native." I'm afraid implies a crucial misunderstanding<br>
> of how OCaml-on-Windows works.</p>
<p dir="ltr">I know that Cygwin is hardly a step towards native windows compatibility and about the cross-compilation tangle. But given the difference in cost, I think it's worth ensuring Cygwin is well supported before attacking the bulk of the problem: you quickly trip over tiny issues even with Cygwin at the moment.</p>
<p dir="ltr">> Related to this, are there general plans at the moment for how OPAM may deal<br>
> with cross-compiling? This becomes relevant with four Windows ports</p>
<p dir="ltr">There is quite some amount of thought about it, but no plan yet.</p>
<p dir="ltr">@Anil, on the "os" variable, we have "cygwin" and "win32", following Sys.os_type().<br></p>
<p dir="ltr">Cheers,<br>
Louis<br></p>
<p dir="ltr">Le dimanche 2 novembre 2014, 20:48:37 David Allsopp a écrit :<br>
> For OCaml 4.02, instead of spending the time I would normally use on a<br>
> compiler upgrade bringing my private build scripts up-to-date, I've been<br>
> doing some work porting OPAM to Windows.<br>
><br>
> I'm chipping away at this - mainly at 'weekends'! - and will publish to<br>
> dra27/opam on GitHub hopefully within the next fortnight (if someone else is<br>
> also actively working on a Windows port and would like to see the stuff<br>
> sooner, then ping me a message - there're just too many hacks on the TODO<br>
> list to bother with pushing commits at the moment). So far I've got opam<br>
> init working (including installing the base packages) though I'm still<br>
> polishing some of the scripts for opam config env. Next up is being able to<br>
> switch to another compiler instance and install some packages, but I'm<br>
> feeling that the bulk of the hard work is already done now.<br>
><br>
> All that said, the main purpose of this message is to offer some comment on<br>
> the portability section of the 1.3 Roadmap<br>
> (<a href="https://github.com/ocaml/opam/wiki/1.3-Roadmap">https://github.com/ocaml/opam/wiki/1.3-Roadmap</a>) which I hope will be<br>
> helpful.<br>
><br>
> * Rewrite the parallel command engine<br>
> This is a 'de facto' requirement for porting to Windows, because it's used<br>
> to install the base packages and removing it was easy. My own code only<br>
> avoids Unix.fork (and Unix.wait) for Windows, but it would be beneficial for<br>
> both Unix and Windows to use the same code path, obviously. I simply<br>
> converted everything to Marshal - the child closure is sent on stdin to<br>
> additional opam processes (using a special --fork command line switch). It<br>
> seems to be working, though some subtleties with global variables might rear<br>
> their heads when I start installing packages and trying to push the --jobs<br>
> switch later.<br>
><br>
> * Native system manipulation<br>
> While I think invocations of wget/curl could beneficially be replaced with<br>
> ocamlnet and tar with ocaml-tar, I think replacing all other calls (rm, cp,<br>
> etc.) this is a bad idea or, at least it should certainly not be done on the<br>
> false altar of making Windows-use better/easier. OPAM is a source-based<br>
> package manager - OCaml itself requires a bash-like environment to compile<br>
> (for *all* Windows ports, including the Microsoft-based ones) and let's not<br>
> forget that a possible bash-free alternative for building OCaml was<br>
> subsequently removed from the source tree. And that's before looking at<br>
> packages - it's naïve to imagine, given the majority of package authors<br>
> being Unix-based in one flavour or another, that there will ever a point<br>
> where anything approaching a majority of package build systems are totally<br>
> shell-agnostic. It seems to me to be much better to head towards a system<br>
> which can expect various standard Unix commands to be available (via Cygwin,<br>
> MSYS, GnuWin32, etc.) but aim not to require the actual shell to be Unix<br>
> (i.e. work within Command Prompt, PowerShell, etc.). In this model, the aim<br>
> is to make Windows sufficiently Unix-like so that supporting Windows becomes<br>
> a matter of small configure-style tweaks already required to support various<br>
> flavours of Unix anyway. In my experience, packages which end up with two<br>
> build systems (the main one, and something hacked for Windows) end up with a<br>
> very stale, broken Windows build system, because the maintainer quite<br>
> reasonably ends up releasing later versions without testing whether the<br>
> Windows build system still works.<br>
><br>
> * Test & fix on Windows<br>
> "Cygwin, then, maybe, native." I'm afraid implies a crucial misunderstanding<br>
> of how OCaml-on-Windows works. I haven't checked, but OPAM should already<br>
> compile for *Cygwin* because Cygwin is simply Unix. The only thing which may<br>
> be broken is the odd configure check (i.e. correctly parsing the output of<br>
> uname). But understand that that means compiling OPAM in *Cygwin*'s OCaml<br>
> (which is OCaml built using ./configure in the normal way, not by using the<br>
> manual files in config/). Having OPAM working for Cygwin is a good idea,<br>
> indeed it'd be a good to have a Cygwin package of OPAM if someone were<br>
> willing to maintain it. But it's a trivial target - virtually nothing should<br>
> require altering, because that's the point of Cygwin. So it's either<br>
> "native" (i.e. the MinGW and MSVC ports) or not really worth talking about!<br>
><br>
> The four Windows ports are cross-compiled using a Cygwin bash shell as the<br>
> *environment* (note that a lot of this can be done using an MSYS bash shell<br>
> as the environment too). But the compilers are all cross-compilers (although<br>
> because the architecture for both compilation and target is the same, most<br>
> configure scripts do not realise that they are cross compiling!) - which is<br>
> why the build system can use things like "/bin/sh" (which Cygwin C runtime<br>
> translates it) but the resulting OCaml environment cannot (because the<br>
> Microsoft Visual C Runtime, unsurprisingly, does not).<br>
><br>
> Fortunately, it's easy to interact with Cygwin commands (rm, cp, etc.)<br>
> because they're all coded to recognise Windows paths if they're specified<br>
> with forward slashes (C:/Windows\system32 is a perfectly valid Windows path<br>
> and, indeed, for the Command Interpreter, even C:/"W"indows\""system32 is a<br>
> valid path!).<br>
><br>
> My experience (based on my own installation of around 45 or so OCaml and<br>
> OCaml-related packages) is that building for Windows usually just involves<br>
> overriding some lazy assumptions in build systems (for example, the most<br>
> common one being the assumption "we're building on Windows" => "object files<br>
> end in .obj") so nothing which can't be quickly committed upstream, or<br>
> applied in opam-repository patches. I don't expect there will be "generic"<br>
> fixes, beyond trying to cp "foo.exe" if "foo" cannot be found in a .install<br>
> file (which I'm coding up anyway in my fork). What may be useful is to have<br>
> certain non-OCaml packages packaged up in OPAM for Windows-only - for<br>
> example, openssl, pcre and so on to deal with libraries which aren't<br>
> normally packaged for Windows.<br>
><br>
> Related to this, are there general plans at the moment for how OPAM may deal<br>
> with cross-compiling? This becomes relevant with four Windows ports - one of<br>
> the big advantages with opam (and the whole model of opam config env) is<br>
> that it will make it much easier to run all four Windows ports on the same<br>
> machine, but it seems very tedious (and difficult to maintain) to need to<br>
> specify every single compiler switch 5 times (e.g. 4.02.0, 4.02.0+msvc,<br>
> 4.02.0+mingw, 4.02.0+msvc64, 4.02.0+mingw64). I was thinking of adding a<br>
> Windows-only (for now) --target option to opam switch for an enumeration of<br>
> auto/mingw/msvc/mingw64/msvc64. So opam switch 4.02.0+foo --target=mingw64<br>
> would build the 64-bit MinGW port of OCaml in ~/.opam/4.02.0+foo+mingw64. It<br>
> would obviously also be useful for opam files to be able to reference the<br>
> value of --target.<br>
><br>
><br>
> David<br>
><br>
> _______________________________________________<br>
> opam-devel mailing list<br>
> <a href="mailto:opam-devel@lists.ocaml.org">opam-devel@lists.ocaml.org</a><br>
> <a href="http://lists.ocaml.org/listinfo/opam-devel">http://lists.ocaml.org/listinfo/opam-devel</a></p>
<p dir="ltr">_______________________________________________<br>
opam-devel mailing list<br>
<a href="mailto:opam-devel@lists.ocaml.org">opam-devel@lists.ocaml.org</a><br>
<a href="http://lists.ocaml.org/listinfo/opam-devel">http://lists.ocaml.org/listinfo/opam-devel</a><br>
</p>
</blockquote>
<p dir="ltr"><br>
</p>