On Fri, 2006-08-04 at 04:40 +0400, Grigory Batalov wrote:

BTW: anyone working on this should examine the Debian Ocaml Policy.
Sorry no link off hand, ask on

debian-ocaml-maint@lists-debian.org

At least any macros should work well with Debian packagers
requirements, people there have high expertise packaging Ocaml
stuff.

In particular .. you should note that 'detecting' ocaml libraries
is VERY HARD because they're locked to a fixed version of Ocaml:
the Ocaml ABI changes with every release (including patches).

AFAIK, you simply cannot 'autoconf' check a required library
is available: the check will not reveal the version of Ocaml
used to build that library .. and it must be built with
the version of Ocaml being used for this tarball build
or the library is useless.

I think what you actually need to do is:

(a) find the appropriate Ocaml program
(b) find the candidate library
(c) check the time stamps on both, and reject the library
unless its date is newer than the ocaml program.

[My own personal solution to this is (a) never use third party
libraries and (b) if I have to, bundle the source code:
always build everything from source. For C this would be
a nightmare .. for Ocaml it is no problem, the compiler
is so fast, and it gives you control of compilation options..
not that there are many]

>   We use OCAMLCDOTOPT for ocamlc.opt and OCAMLOPTDOTOPT for ocamlopt.opt
>   inside AC_PROG_OCAML macro, but they are not available to user yet.
> 
>   It seems like optimized tools work faster (?). What if we will prefer
>   optimized tools by default, but switch to bytecoded if user gives
>   --without-opttools configure argument ?

I think you have this procedure:

(a) you detect and set variable for support for

native compiler: one of: ocamlopt.opt, ocamlopt
bytecode compiler: one of: ocamlc.opt, ocamlc

interface compiler: one of: ocamlc.opt, ocamlc
 (this is the same program as bytecode compiler, but it 
  should be managed separately)

plus other tools (ocamldep, ocamldoc, findlinb, etc).

(b) There at least are 3 models of compilation:

native code, bytecode, standalone bytecode
(the latter is a single executable file containing the 
bytecode interpreter and bytecode in one package).

The user has several choices:

1. Chose fastest model: 
  native code if possible, otherwise bytecode

2. Chose standalone executable (rare):
  native code if possible, otherwise standalone bytecode

3. Chose bytecode

4. Chose native code

5. BOTH bytecode and nativecode 

Developers often want (5) both, but it plays interesting
havoc with naive build scripts: the generated programs
must have distinct names (libraries and object files
already do).

My own build system can't handle this :)

> > Fourth, in the AC_PROG_FINDLIB, there is a switch allowing the user to
> > disallow the use of ocamlfind, even if present on the system. Why is
> > thie behaviour desirable ?
> 
>   I guess, we have found a broken findlib on some platform and desided
>   to optionally disable it.

Also because a developer may want to check a system builds
without requiring findlib.

but the real reason is simpler: some people write Makefiles
which require findlib, and will not work without it.

Some people write Makefiles that will not work with it.

Some people try to support both.


-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net