caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Max Skaller <maxs@in.ot.com.au>
To: Markus Mottl <mottl@miss.wu-wien.ac.at>
Cc: OCAML <caml-list@inria.fr>
Subject: Re: Portability of applications written in OCAML: C stuff
Date: Thu, 24 Feb 2000 13:55:57 +1100	[thread overview]
Message-ID: <38B49DBD.8DCBB87A@in.ot.com.au> (raw)
In-Reply-To: <200002231831.TAA11195@miss.wu-wien.ac.at>

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



  reply	other threads:[~2000-02-24 14:32 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-02-15 13:01 Portability of applications written in OCAML Claude Marche
2000-02-16 13:09 ` Jean-Francois Monin
2000-02-16 14:08   ` Claude Marche
2000-02-16 14:28     ` Jean-Francois Monin
2000-02-18  9:18     ` Patrick Goldbronn - SYSCO
2000-02-16 22:49 ` Gerd Stolpmann
2000-02-18  9:36   ` Xavier Leroy
2000-02-21 20:45     ` skaller
2000-02-22  8:13     ` Sven LUTHER
2000-02-22  9:21       ` Xavier Leroy
2000-02-22 23:43         ` Portability of applications written in OCAML: C stuff Max Skaller
2000-02-23 18:31           ` Markus Mottl
2000-02-24  2:55             ` Max Skaller [this message]
2000-02-24 14:44               ` Sven LUTHER
2000-02-24 15:04               ` Alan Schmitt
2000-02-24 23:51                 ` Max Skaller
2000-02-25  8:37                   ` Alan Schmitt
2000-02-25 16:58                     ` skaller
2000-02-24 20:17               ` Gerd Stolpmann
2000-02-25  0:35                 ` Max Skaller
2000-02-25 13:21                   ` STARYNKEVITCH Basile
2000-02-17  8:05 ` Portability of applications written in OCAML skaller
2000-02-25 12:29 Portability of applications written in OCAML: C stuff Juergen Pfitzenmaier
2000-02-25 16:51 ` skaller
2000-02-25 14:05 Juergen Pfitzenmaier
2000-02-26 18:47 Juergen Pfitzenmaier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=38B49DBD.8DCBB87A@in.ot.com.au \
    --to=maxs@in.ot.com.au \
    --cc=caml-list@inria.fr \
    --cc=mottl@miss.wu-wien.ac.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).