From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: weis Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id PAA21253 for caml-redistribution@pauillac.inria.fr; Thu, 24 Feb 2000 15:32:20 +0100 (MET) Resent-Message-Id: <200002241432.PAA21253@pauillac.inria.fr> Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id DAA22691 for ; Thu, 24 Feb 2000 03:50:21 +0100 (MET) Received: from ot-link.ot.com.au ([203.5.3.1]) by nez-perce.inria.fr (8.8.7/8.8.7) with SMTP id DAA05098 for ; Thu, 24 Feb 2000 03:50:16 +0100 (MET) Received: (qmail 4792 invoked from network); 24 Feb 2000 02:50:13 -0000 Received: from unknown (HELO druid.in.ot.com.au) (203.5.4.202) by 203.5.4.251 with SMTP; 24 Feb 2000 02:50:13 -0000 Received: (qmail 19813 invoked from network); 24 Feb 2000 02:50:11 -0000 Received: from merlin.in.ot.com.au (HELO in.ot.com.au) (203.5.4.26) by druid.in.ot.com.au with SMTP; 24 Feb 2000 02:50:11 -0000 Sender: maxs@inria.fr Message-ID: <38B49DBD.8DCBB87A@in.ot.com.au> Date: Thu, 24 Feb 2000 13:55:57 +1100 From: Max Skaller Organization: Open Telecommunications Ltd X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Markus Mottl CC: OCAML Subject: Re: Portability of applications written in OCAML: C stuff References: <200002231831.TAA11195@miss.wu-wien.ac.at> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-From: weis@pauillac.inria.fr Resent-Date: Thu, 24 Feb 2000 15:32:20 +0100 Resent-To: caml-redistribution@pauillac.inria.fr Markus Mottl wrote: > > > The way these packages are distributed is a 'build in separate > > directory and install' model. This is NOT acceptable for my > > package. I require all components to be built and usable > > WITHOUT installing them (with one exception: the standard ocaml (and > > python) > > distributions). > > Hm, I don't know about "mlgtk", but what concerns the PCRE, you need not > install it anywhere to use it. The only thing you have to do is place > directory "{whatever}/pcre_ocaml/pcre-OCaml" on the include- and the > library path when you compile/link your project. This model doesn't really work for me. Consider that typically this requires 1) run .configure 2) run make This is not acceptable. My rules are: after the client untars the distribution of my product, they may have to edit part of the build script, 'maker' which is written in Python. Then they say 'python maker' and the build has to work without any other intervention. Make and autoconf are not permitted: any work these do must be done by ME in the 'maker' script IN PYTHON. In particular, while my product is currently Unix only, the build process must work under Windows too, which rules out make, autoconf, and other such silliness. :-) > "config.h" is generated by "configure" automatically and is actually part > of the C-library "pcre", which I always copy verbatim from its author. > Unless you also copy this "configure"-script out of its assigned directory > into your source dir, it won't do any harm to your files. pcre cannot build without config.h, and neither can mlgtk. So there is a conflict, since both require a file called 'config.h'. > > PLEASE use filenames that are specialised to your package, > > do NOT use generic names on the assumption your code will > > be built with your Makefile in a separate directory. > > This is impossible. It is not impossible to try. > How do you want to guarantee that files of other people > don't get overwritten if you mix some distribution with theirs? I guarrantee it, since I am combining the sources. > That's what directories are for! I do not wish to build and mess around with subpackages in directories, which amount to a small part of my overall package: pcre, for example, corresponds to a single library module with a few functions in it. There are hundreds of functions to build, and I want the sources all in the SAME directory. When ocaml supports packages with subdirectory structures natively, THEN I will require the client install third party packages, rather than distributing them as an integral part of my source. > I agree on this: a standard way for adding libraries, etc., would probably > boost productivity... Enormously -- but I will be happy to wait until it can be done right, since it is VERY hard to 'fix' a broken design here. {The python model is OK, but not perfect} -- John (Max) Skaller at OTT [Open Telecommications Ltd] mailto:maxs@in.ot.com.au -- at work mailto:skaller@maxtal.com.au -- at home