[resending because in the former mail my comment was inlined]<br><br><div class="gmail_quote">Le Tue Nov 04 2014 at 8:42:09 AM, Louis Gesbert <<a href="mailto:louis.gesbert@ocamlpro.com">louis.gesbert@ocamlpro.com</a>> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks for these comments !<br>
<br>
* Rewrite the parallel command engine<br>
<br>
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. <br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Native system manipulation<br>
<br>
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.<br></blockquote><div><br></div><div><pre style="white-space:pre-wrap;color:rgb(0,0,0);line-height:normal">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 it. POSIX implementation of those command require some work.</pre><pre style="white-space:pre-wrap;color:rgb(0,0,0);line-height:normal"><br></pre><pre style="white-space:pre-wrap;color:rgb(0,0,0);line-height:normal">ocaml-fileutils has also a low number of dependencies that makes it more suitable for inclusion.</pre></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
* Test & fix on Windows<br>
> "Cygwin, then, maybe, native." I'm afraid implies a crucial misunderstanding<br>
> of how OCaml-on-Windows works.<br>
<br>
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.<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<br>
<br>
There is quite some amount of thought about it, but no plan yet.<br>
<br>
@Anil, on the "os" variable, we have "cygwin" and "win32", following Sys.os_type().<br>
<br>
<br>
Cheers,<br>
Louis<br>
<br>
<br>
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" target="_blank">https://github.com/ocaml/<u></u>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/<u></u>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>
> ______________________________<u></u>_________________<br>
> opam-devel mailing list<br>
> <a href="mailto:opam-devel@lists.ocaml.org" target="_blank">opam-devel@lists.ocaml.org</a><br>
> <a href="http://lists.ocaml.org/listinfo/opam-devel" target="_blank">http://lists.ocaml.org/<u></u>listinfo/opam-devel</a><br>
<br>
______________________________<u></u>_________________<br>
opam-devel mailing list<br>
<a href="mailto:opam-devel@lists.ocaml.org" target="_blank">opam-devel@lists.ocaml.org</a><br>
<a href="http://lists.ocaml.org/listinfo/opam-devel" target="_blank">http://lists.ocaml.org/<u></u>listinfo/opam-devel</a><br>
</blockquote></div>