From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 0F9697EF28 for ; Fri, 26 Jun 2015 10:18:01 +0200 (CEST) X-IronPort-AV: E=Sophos;i="5.13,683,1427752800"; d="scan'208";a="167404662" Received: from meleze.ens.fr (HELO [129.199.99.114]) ([129.199.99.114]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 26 Jun 2015 10:18:00 +0200 Message-ID: <558D0AB8.9050902@inria.fr> Date: Fri, 26 Jun 2015 10:18:00 +0200 From: Francois Berenger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: caml-list@inria.fr References: <1e86d3d4e5a1e3ba3051d8c928b0dbd2@in.tum.de> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Caml-list] OCaml embedded On 06/26/2015 05:04 AM, Berke Durak wrote: > On Tue, Jun 23, 2015 at 6:32 AM, Markus Weißmann > wrote: >> >> I can offer experience in the following cases: >> 1) If your system is powerful enough (e.g. rasperry pi), you can just install the ocaml toolchain on your system and develop there on your target system. > > Seconded. We did almost that for one of our projects and it works > pretty well. The difference is that we didn't use QEmu, but two of > our custom Q7 board (based on a Zynq ARM Cortex A9 with 512 MB RAM, > see http://xiphos.com/products/q7-processor/ ). > > We use Yocto to generate two versions of a Linux system: the target > system, and a much larger version that contains developer tools (C > compiler, m4, etc.) The development system runs from microSD cards, > and takes the better part of a gigabyte, while the target system has > to run from < 64 megs of flash. The required run-time dependencies of > the target system have to be manually configured in the Yocto recipes. > > We then manually install opam on the developer board, and use it to > compile our OCaml code. The generated native ARM executables are then > packaged into .ipks and transferred to the target Q7 board (connected > to actual hardware: > http://www.ghgsat.com/wp-content/uploads/2015/03/Payload-Selfie.jpg ) > The packaging is done using a simple shell script that invokes ar and > tar. > > We did try using QEmu but it's significantly slower, however it may > come into play as automating the build process (using a virtual > machine or dedicated hardware) is on our to do list, and build time > isn't as important when it's a nightly automated build. > > Initially we looked into using a cross-compiler but we decided that > being able to use Opam largely outweighs any possible benefit we could > get from cross-compiling. If the feature request for opam called opam-mkbundle cf. https://github.com/ocaml/opam/issues/929 is implemented some day, this would allow people to ship ocaml software as source code without requiring end users to install opam. > And cross-compiling is often a source of > headaches, even when compiling plain old C. We would have to write a > lot of Yocto recipes to get it running. Note that Yocto is written in > a progarmming language called Python and requires recipes to be > expressed mostly the same language. > > To conclude, as powerful ARM systems are very cheap and plentiful > these days, and since the convenience of Opam is immense, I'm not sure > there is much incentive in using a cross-compiler. BTW, is there a > maintained ARM cross-compiler? > -- Regards, Francois. "When in doubt, use more types"