Version française
Home     About     Download     Resources     Contact us    
Browse thread
Why don't you use batteries?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Adrien <camaradetux@g...>
Subject: Re: [Caml-list] Why don't you use batteries?
You seem to have a pretty nice list of packages on windows^Wmingw. :)

Reason #1 could also be solved by publishing your patches and having
them merged upstream. ;-)

>From what you said, your patches won't be very clean and won't be
mergeable in their current state (hardcoding paths, I've been there
too) but they would at least show where the problems are and that's
maybe the biggest part of the work. Please share them if you can.

 ---

Adrien Nader

On 06/09/2009, dmitry grebeniuk <gdsfh1@gmail.com> wrote:
> 2009/9/5 David Allsopp <dra-news@metastack.com>:
>
>> I'm not sure that one is allowed to redistribute the Microsoft C compilers
>> directly without a license, but packaging MSYS or the relevant parts of
>> Cygwin along with OCaml and Batteries would create an installer somewhere
>> between 150-300MB which compared to the 16GB of trial software I
>> downloaded
>> from the Microsoft website the other day is not that bad.
>
>  That's what I'm doing for my local needs, approximately.  First of
> all, I have an infrastructure to build so called "packages".  global
> configure script (allows to choose installation prefix, library
> paths), a lot of patches, platform-specific build scripts, some
> dependency-stuff.  Patches allow me to hardcode paths in some places
> (ugly, but it works).  I'm building it under platforms that are
> interesting for me, for now it's only mingw/win32 and ubuntu, maybe
> I'll build under freebsd later.  I'm enjoying the pleasure of patching
> everything: for example, I made ocamlnet (fastcgi part) working on
> mingw.  "Packages" are building and working both under mingw and
> linux. (working as far as I have tested -- using "test" targets when
> available, or using the library in my code).  The selection of
> packages is incomplete, but that's the packages I'm using and its
> dependencies: camltemplate camlzip camomile cryptokit deriving extlib
> findlib json-static lablgtk2 lwt menhir objsize ocaml-bitstring
> ocaml-sqlite3 ocaml-ssl ocamlgraph ocamlnet omake ounit pa_do
> pa_safeuse pcre-ocaml sexplib type-conv ulex xmlm.  (there are no
> batteries for now)
>
>  Then, some revisions of my project become binary.  I'm making 4
> zip-archives under windows: 1. base installation of mingw, msys,
> tcl/tk, gtk+ in standard places (c:\mingw, etc), 2. archive that adds
> unpacked .tar.gz with mingw C libraries, 3. archive that contains
> compiled ocaml + findlib, 4. archive with other ocaml libraries.  So,
> installing fresh ocaml and libraries under fresh win32 is just
> unpacking 4 zip-archives in c:\ , and adding something like "call
> c:\ocaml\set-vars.bat" or ". c:/ocaml/set-vars.sh" in build script.
>
>  I don't distribute it mainly because of the following reasons.  1.
> License questions for binary builds.  For my local needs I can do
> whatever I want, until it doesn't leave my host and nobody sees it.
> (so, guys, you haven't seen all what I've described before)  2. The
> complexity of building the system from sources under windows: approx
> 17 files to download, some of them you install, others you unpack
> (.tar.gz, .tar.bz2, not very comfortable for windows).  3. I don't
> want to support cygwin (I'm even not installing it at all), and I
> don't support msvc and win64 architectures (I don't need it for now).
>  Maybe the reason#1 can be solved by building ocaml compiler without
> my local patches and reading licenses carefully.
>
> _______________________________________________
> 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
>