Version française
Home     About     Download     Resources     Contact us    
Browse thread
Portability of applications written in OCAML
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Max Skaller <maxs@i...>
Subject: Re: Portability of applications written in OCAML: C stuff
I have a problem using some third partyC 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