From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id E13F0BB84 for ; Sun, 15 Jun 2008 23:42:05 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikCAEspVUjAXQIniGdsb2JhbACRXEMBAQEPIJZDglkB X-IronPort-AV: E=Sophos;i="4.27,649,1204498800"; d="scan'208";a="14035757" Received: from concorde.inria.fr ([192.93.2.39]) by mail3-smtp-sop.national.inria.fr with ESMTP; 15 Jun 2008 23:42:05 +0200 Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id m5FLg4wH002143 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=OK) for ; Sun, 15 Jun 2008 23:42:04 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjkBAA8pVUjRVcbveGdsb2JhbACRXEMBDAUCBgcPBZY+glkB X-IronPort-AV: E=Sophos;i="4.27,649,1204498800"; d="scan'208";a="13863892" Received: from rv-out-0506.google.com ([209.85.198.239]) by mail1-smtp-roc.national.inria.fr with ESMTP; 15 Jun 2008 23:42:03 +0200 Received: by rv-out-0506.google.com with SMTP id k40so4383203rvb.57 for ; Sun, 15 Jun 2008 14:42:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=hklc/lxA0MBEvXY/fGcCHOs0BNwSAer6CDNSJ93Bx4s=; b=wAMf+OjA1n0SyGA8CdsgSkMVOZfPe/UKaRGol+OxSQU7A+OdwFDTNa61MBFNxqMef6 N7WlC93OhTr88FjjsJ7mTxMlB2PKLDEKj+WIxZZLJ9/YSKrwnwfcILhd2KlihbrwT/4e FcfV23wJi1wlFkaLObUlB90Pd/waqTZbtldrw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=bse1RC3mpqBjQ1zH1pJZQbD3Vk3yahuQ0phCuG25kEjIoa/R6R2kPjvVoTmdXqLozu UCSi/6RFd9daJhvM1kGspP9V+fDzqFmWtWediM4vsuZkzOMXoYIfP+ajujb12VbkV77K c4UlhCI8/r1OihY13xx9a3uinx57FpabvNvLA= Received: by 10.141.128.19 with SMTP id f19mr207013rvn.107.1213566122272; Sun, 15 Jun 2008 14:42:02 -0700 (PDT) Received: by 10.141.116.8 with HTTP; Sun, 15 Jun 2008 14:42:02 -0700 (PDT) Message-ID: <666572260806151442u2e45ac66o9eac3ea88e4d8903@mail.gmail.com> Date: Sun, 15 Jun 2008 23:42:02 +0200 From: Adrien To: "Gerd Stolpmann" Subject: Re: [Caml-list] GODI News: RocketBoost Beta Cc: caml-list , godi-list In-Reply-To: <1213553160.22235.117.camel@flake.lan.gerd-stolpmann.de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1213541678.22235.107.camel@flake.lan.gerd-stolpmann.de> <666572260806150932i793fd09dse7fb537a8d9df4af@mail.gmail.com> <1213553160.22235.117.camel@flake.lan.gerd-stolpmann.de> X-Miltered: at concorde with ID 48558CAC.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; gerd:01 stolpmann:01 byterun:01 byterun:01 ocaml:01 ocaml:01 gerd:01 stolpmann:01 mingw:01 cygwin:01 mingw:01 o'caml:01 o'caml:01 gcc:01 tarball:01 2008/6/15 Gerd Stolpmann : > > Am Sonntag, den 15.06.2008, 18:32 +0200 schrieb Adrien: >> Hi, >> >> First, thanks for your work for the windows platform. >> >> I've just tried this beta. Overall it worked quite well (it compiled >> during about one hour on a quite recent machine and installed 260MB of >> data) but failed in the end. Here are the last lines (I haven't logged >> everything but this could be enough) : >> >> > + /home/Administrateur/godi-rocketboost-20080615/run/ocamlrun-3.09.3/byterun/ocamlfatrun /home/Administrateur/godi-rocketboost-20080615/godi-tools-boot/boot_console delete -f godi-tools >> > Warning: Package godi-tools is protected against deletion. >> > Deleting anyway. >> > + /home/Administrateur/godi-rocketboost-20080615/run/ocamlrun-3.09.3/byterun/ocamlfatrun /home/Administrateur/godi-rocketboost-20080615/go >> > di-tools-boot/boot_console add /ocaml/build/packages/All/godi-tools-2.0test31.tgz >> > + exec /ocaml/sbin/godi_console perform -tmpdir-state /tmp/godi4632-0:1 >> > Fatal error: cannot find file perform >> > Failure! > > That's quite strange. I have no idea what it is, but it is harmless. > Actually, this last command does not nothing, so GODI is installed. > > Can you check whether the newly installed godi_console works? A good > test is > > godi_console perform -build godi-tools > > so it builds itself again using the new godi_console (and not the > bootstrap version). Well, it doesn't work : Administrateur@Chewbacca ~ $ godi_console perform -build godi_tools Fatal error: cannot find file perform I had some weird feeling about this so I tried strings on godi_console and in fact... Administrateur@Chewbacca ~ $ cat `which godi_console` #! /bin/sh exec /home/Administrateur/godi-rocketboost-20080615/run/ocamlrun-3.09.3/byterun/ocamlfatrun /home/Administrateur/godi-rocketboost-20080615 /godi-tools-boot/boot_console "$@" I guess it failed at some point during installation but I really don't know when. I'll try another installation on tomorrow. >> I have time to install godi from scratch so if you need anything, >> don't hesitate. :) > > Thanks for your help. > >> Btw, is there any chance the PATH gets automatically updated ? >> I've installed ocaml by hand several times but I keep on forgetting this step. > > Well, you would need to do it in your login setup, e.g. .bashrc. The > bootstrap script just cannot do it. > > What we can talk about is that stage2 is automatically called. I think it's alright this way. I just always forget the PATH thing. I think I'll have a tatoo or something like that, that should do the trick. --- Adrien Nader >> 2008/6/15 Gerd Stolpmann : >> > Hi, >> > >> > In the past weeks I've worked hard to finish the next GODI release, >> > focusing on portability. A beta version of the new bootstrap and >> > godi_console, called RocketBoost, is now available, and it would be >> > great if it were tested at large. >> > >> > There are not many new features in this release, so there is no reason >> > to switch to it if you already have GODI. >> > >> > The big news is that GODI now supports the MinGW port of OCaml for >> > Windows (besides the Cygwin port). This means that it is now possible to >> > create native Windows applications with GODI. Note, however, that the >> > porting effort is still in its beginning - GODI itself works, but most >> > packages aren't ported yet, and won't work. >> > >> > The MinGW support has become possible because large parts of the GODI >> > core have been rewritten. In particular, the C programs accompanying >> > godi_console are now coded in O'Caml (godi_make, godi_add, etc.), so >> > porting was possible by enhancing a few O'Caml libraries. This >> > refactoring of GODI also increases the portability in the Unix world - >> > effectively it should now run on all platforms where OCaml runs, where >> > gcc is available, and where POSIX-compliant shell utilities are >> > available. >> > >> > If you would like to test it, follow these instructions. For all ports, >> > you need the bootstrap tarball from: >> > >> > http://download.camlcity.org/download/godi-rocketboost-20080615.tar.gz >> > >> > >> > >> > --- Installation for Unix --- >> > >> > For Unix platforms (including MacOSX), just download >> > godi-rocketboost-20080615.tar.gz, unpack it, run ./bootstrap, and follow >> > the instructions. >> > >> > >> > >> > --- Installation for Windows --- >> > >> > For Windows you always need Cygwin, even for the MinGW port (it is >> > needed as scripting environment, please don't question that). Get it >> > from cygwin.com. Install everything that is needed (binutils, bzip2, >> > diffutils, file, findutils, gawk, gcc-core, gcc-mingw-core, grep, groff, >> > gzip, m4, make, man, mingw-runtime, patch, rxvt, sed, tar, w32api, wget >> > - hope this list is complete). >> > >> > IMPORTANT: When you install software you need for GODI, choose paths >> > that do not contain space characters. This is incompatible with the >> > shell scripts. So don't install into "My Files". >> > >> > Download godi-rocketboost-20080615.tar.gz, and unpack it: >> > >> > $ tar xzf godi-rocketboost-20080615.tar.gz >> > $ cd godi-rocketboost-20080615 >> > >> > Now invoke bootstrap. You probably want to set the path where it is >> > going to be installed with -prefix. Furthermore, you can now select >> > whether you want the Cygwin or the MinGW port. For the latter, pass >> > "-w32port mingw" as extra argument. >> > >> > IMPORTANT: Remember that GODI itself relies on Cygwin scripting. If you >> > pass paths to GODI (including godi_console, godi_add, etc.) these are >> > Cygwin paths, even if you build the MinGW port. >> > >> > $ ./bootstrap -prefix /home/gerd/godi -w32port mingw >> > >> > This will build boot_console. Then you need an Internet connection, and >> > do: >> > >> > $ export PATH=/home/gerd/godi/bin:/home/gerd/godi/sbin:$PATH >> > $ ./bootstrap_stage2 >> > >> > This will install the minimal GODI core. >> > >> > IMPORTANT: godi_console isn't ported to the Windows console window, and >> > for now only supports terminal windows that can deal with ANSI control >> > codes. Use Cygwin's rxvt as terminal (or any other capable terminal like >> > xterm). Furthermore, there is an issue with the MinGW port setting some >> > terminal features. As workaround, you have to set the TTY environment >> > variable to the Cygwin tty device, i.e. TTY=`tty`. >> > >> > Note that the MinGW port is only available for ocaml-3.10. Passing >> > "-section 3.09" to bootstrap won't work. >> > >> > >> > --- List of problems --- >> > >> > The final part of this message lists some problems that popped up during >> > the MinGW porting effort. I have often found workarounds, but maybe the >> > reader knows better solutions. >> > >> > * Cygwin interoperability >> > >> > A lot of the porting effort was about Cygwin interoperability. >> > godi_console (which is a native Win32 binary) can translate Cygwin paths >> > to native Windows paths (by reading the Cygwin mount table in the >> > registry). However, some problems turned out to be hard: >> > >> > Starting a Cygwin binary with CreateProcess from godi_console turned out >> > to be unreliable when godi_console was itself called from a Cygwin >> > program. So the calling chain Cygwin_pgm -> Win32_pgm -> Cygwin_pgm >> > did not always work (symptom: the called program immediately exits). A >> > workaround was to use cmd.exe as intermediate instance: >> > Cygwin_pgm -> Win32_pgm -> cmd.exe -> Cygwin_pgm >> > >> > Maybe related to that, it wasn't possible to run stty without explicit >> > device argument. (godi_console needs to call it to talk to the Cygwin >> > tty driver.) stty (and tty, too) always complained that stdin wasn't a >> > tty. The workaround is to ask the user to set the environment variable >> > TTY to the tty device. >> > >> > * Cygwin vs. Windows file names >> > >> > The approach is that GODI itself is seen as a Cygwin program - although >> > godi_console is a native program. As already mentioned, godi_console is >> > capable of translating Cygwin paths without using Cygwin. >> > >> > At some time, it is required to translate paths to the Windows style, >> > because programs like ocaml, ocamlfind, etc. are Windows executables >> > without Cygwin path translation capability. In GODI Makefiles, there is >> > now always the variable $(LOCALBASE_NATIVE), set to the Windows path >> > (using forward slashes). The porting effort was effectively quite low - >> > in a few places I had to use ${LOCALBASE_NATIVE} instead of >> > ${LOCALBASE}. >> > >> > * CR/LF >> > >> > In godi_console, it was required to look carefully over the code, and to >> > switch between ASCII and binary channel modes where needed. As native >> > Windows executable, godi_console uses CR/LF as EOL characters. >> > >> > It turned out that Cygwin's bash has sometimes problems with CR/LF. >> > Especially, something like >> > >> > stdlib=`ocamlc -where` >> > >> > does not work - the CR character remains as part of the result value. >> > The workaround was to use Cygwin's alternate shell, ash, in these cases, >> > which handles that better. >> > >> > * cygpcre DLL, and DLL lookup by PATH >> > >> > Cygwin includes a PCRE DLL. Of course, this DLL cannot be used in >> > non-Cygwin programs, so GODI always installs its own PCRE DLL. >> > >> > It turns out that the MinGW install of PCRE produces a DLL with the same >> > name as the Cygwin version (cygpcre-0.dll, as far as I remember). As >> > DLL's are looked up by PATH, and we _need_ the Cygwin directories in >> > PATH, the problem arises how to direct MinGW executables to use the >> > right DLL. >> > >> > For now the workaround is that the MinGW version has a different version >> > number (cygpcre-7.dll). It would be nice, however, to get rid of the >> > "cyg" prefix for a clearer separation of DLL spaces. >> > >> > * Ocaml does not install ocamldep.opt.exe >> > >> > in the MinGW port. Maybe an oversight? >> > >> > * No support for ocamlmklib >> > >> > A lot of work has been put into working around the missing ocamlmklib. >> > The difficulty is that stub libraries need to be compiled with different >> > flags when a DLL is to be produced, i.e. the C compiler is invoked >> > differently in this case. This is incompatible with many build Makefiles >> > that can only produce one version of .o files from a .c file. Because of >> > this difficulty, ocamlmklib isn't available. >> > >> > For ocamlnet, I worked around by using two scripts, stubcc, and >> > mkstublib, available from >> > >> > https://godirepo.camlcity.org/svn/godi-build/trunk/godi/godi-ocamlnet/files/ >> > >> > Effectively, stubcc calls the C compiler twice, and produces a .d.o >> > intended for DLL inclusion, and a normal .o for the static library. I'm >> > wondering whether such a tool could be included in the ocaml >> > distribution, or whether ocamlc could have a special -for-stublib option >> > so that it invokes gcc twice for .c files. >> > >> > * Windows "execv" is broken with respect to "wait" >> > >> > When a windows process calls execv to invoke another binary, it is >> > signaled to the parent process that the program is finished. (The >> > correct POSIX behavior is to wait until the second binary is finished.) >> > In many places, it was easy to work around the problem by using the >> > spawn calls. At one place, this is not possible, and godi_console has to >> > use "execv" to avoid deadlocks. As consequence, it may happen that the >> > caller of godi_console thinks that the program is done although it is >> > still running. >> > >> > No workaround yet. >> > >> > * No real argv support in Windows >> > >> > There are no clear rules how to quote arguments in Windows (cmd.exe). >> > (Actually, there is no list of arguments (argv) in Windows, but only a >> > command line string.) In GODI, it sometimes happens that quoted >> > arguments need to be quoted (and more complicated), and this did not >> > work in Windows. The workaround is to write complex commands to >> > temporary files, and to run these by /bin/sh. >> > >> > * No signals in Windows >> > >> > There is no clear way how to signal a process to terminate itself. As a >> > consequence, aborting builds is broken in godi_console. >> > >> > * argv.(0) is broken >> > >> > I don't know who is to blame for this, either Windows, or Cygwin. At >> > least it wasn't possible to pass a name as argv.(0) that differed from >> > the executable name. >> > >> > The workaround was to use wrapper programs. >> > >> > >> > >> > Anyway, I hope you like the new port. And remember: be patient. Windows >> > is very slow when used for shell-style scripting. >> > >> > Gerd >> > -- >> > ------------------------------------------------------------ >> > Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany >> > gerd@gerd-stolpmann.de http://www.gerd-stolpmann.de >> > Phone: +49-6151-153855 Fax: +49-6151-997714 >> > ------------------------------------------------------------ >> > >> > >> > _______________________________________________ >> > Caml-list mailing list. Subscription management: >> > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list >> > Archives: http://caml.inria.fr >> > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners >> > Bug reports: http://caml.inria.fr/bin/caml-bugs >> > >> > -- > ------------------------------------------------------------ > Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany > gerd@gerd-stolpmann.de http://www.gerd-stolpmann.de > Phone: +49-6151-153855 Fax: +49-6151-997714 > ------------------------------------------------------------ > > >