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 OAA24383 for caml-redistribution@pauillac.inria.fr; Fri, 25 Feb 2000 14:02:50 +0100 (MET) Resent-Message-Id: <200002251302.OAA24383@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 WAA24525 for ; Thu, 24 Feb 2000 22:02:01 +0100 (MET) Received: from beach.frankfurt.netsurf.de (beach.frankfurt.netsurf.de [194.64.181.2]) by nez-perce.inria.fr (8.8.7/8.8.7) with ESMTP id WAA03566 for ; Thu, 24 Feb 2000 22:02:00 +0100 (MET) Received: from ice.darmstadt.netsurf.de (board-74.darmstadt.netsurf.de [194.163.86.202]) by beach.frankfurt.netsurf.de (8.8.5/8.8.5) with ESMTP id WAA03362; Thu, 24 Feb 2000 22:01:57 +0100 (MET) Received: from localhost (localhost [[UNIX: localhost]]) by ice.darmstadt.netsurf.de (8.9.3/8.9.3) id WAA24709; Thu, 24 Feb 2000 22:01:52 +0100 From: Gerd Stolpmann Reply-To: Gerd.Stolpmann@darmstadt.netsurf.de Organization: privat To: Max Skaller , Subject: Re: Portability of applications written in OCAML: C stuff Date: Thu, 24 Feb 2000 21:17:51 +0100 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain References: <200002231831.TAA11195@miss.wu-wien.ac.at> <38B49DBD.8DCBB87A@in.ot.com.au> In-Reply-To: <38B49DBD.8DCBB87A@in.ot.com.au> MIME-Version: 1.0 Message-Id: <00022422015100.15222@ice> Content-Transfer-Encoding: 8bit Resent-From: weis@pauillac.inria.fr Resent-Date: Fri, 25 Feb 2000 14:02:50 +0100 Resent-To: caml-redistribution@pauillac.inria.fr On Thu, 24 Feb 2000, Max Skaller wrote: >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. :-) We all know that Windows is not a serious operating system because it lacks support for many tasks we all EXPECT from an operating system. This is one of the reasons why I do not offer Windows support for my components. You have only two possibilities: (A) reinventing the wheel by writing tools yourself; (B) not offering special Windows support. Please don't blame us that it is difficult to implement (A). I would say that your build process is ... mhhh ... strange. If I did it with only limited means, I would still distinguish between source directories, and a (temporary) installation directory, say: lib: the installation directory source1, source2, ...: source directories Simply compile the sources one after another (in a fixed order), and install the results in lib. While compiling the sources, include -I ../lib such that the previous results can be used in the next compilation step. This is simple enough to be implemented even without Makefiles and autoconf. >> "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'. As far as I know you cannot choose the name of "config.h"; this is hard-wired in autoconf. >> 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. Your argumentation is ridiculous. I often have directories with only very few files if there good reasons to create them. In general I would argue that directories reduce the mess. > 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. Why do you need a "native" package implementation? I think there are good reasons to have one (e.g. a uniform installation procedure), but in your case you can use ANY package mechanism (I have one), simply distribute it with your sources. >> 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} What does "right" mean? It depends on your expectations. For example, I think a package mechanism should not include any build functionality (some kind of "make") because there are already good solutions (even for Windows (cygwin)). Gerd -- ---------------------------------------------------------------------------- Gerd Stolpmann Telefon: +49 6151 997705 (privat) Viktoriastr. 100 64293 Darmstadt EMail: Gerd.Stolpmann@darmstadt.netsurf.de (privat) Germany ----------------------------------------------------------------------------