caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Max Skaller <maxs@in.ot.com.au>
Cc: caml-list@inria.fr
Subject: Re: Portability of applications written in OCAML: C stuff
Date: Wed, 23 Feb 2000 10:43:46 +1100	[thread overview]
Message-ID: <38B31F32.3F0641F4@in.ot.com.au> (raw)
In-Reply-To: <20000222102116.38250@pauillac.inria.fr>

I have a problem using some third party\x03C codes with ocaml,
this includes pcre (defintely) and possibly mlgtk.
Some work needs to be done figuring out the right way to do this.
Here's the problem:

I am distributing an ocaml/C tool which uses third party
components like mlgtk and pcre which require C code.

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). 

What I do is copy relevant source files
from distributed packages, and, if necessary, edit them,
then I build them as part of my system, directly from these
sources.

[In other words I must distribute IN MY PACKAGE everything
which is not stock standard in the official ocaml distribution,
and a single command must build the whole system]

This is a pain. I would like to ask suppliers of third party
packages please

	1. DO NOT USE A FILE CALLED 'config.h'
	  
	Such a file will clobber someone elses config.h
	Pleae call these files 'pcre_config.h' or 'gdk_config.h'
	or whatever.

	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.

	2. Do NOT require you package be 'main'.
	Only ONE main is allowed, and it is MINE.
	Do NOT supply 'main' in ANY C libraries.
	(you can supply a sample 'main.c', but is must be that: a sample)

	[This also seems to affect 'numerix']


Some of these problems will be alieviated when Ocaml gets a proper
mechanism to add components to the system. This is non-trivial,
but it is handled much better in Python than Ocaml at present.

I have made quite extensive additions to mlgtk, but I cannot
supply a 'patch' to the original authors because I have been
forced to rename files, and make edits which break that packages
build model.

-- 
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-23 17:50 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         ` Max Skaller [this message]
2000-02-23 18:31           ` Portability of applications written in OCAML: C stuff Markus Mottl
2000-02-24  2:55             ` Max Skaller
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=38B31F32.3F0641F4@in.ot.com.au \
    --to=maxs@in.ot.com.au \
    --cc=caml-list@inria.fr \
    /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).