Version française
Home     About     Download     Resources     Contact us    
Browse thread
ocaml support in autotools
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Guillaume Rousse <Guillaume.Rousse@i...>
Subject: Re: [Caml-list] Re: ocaml support in autotools
I'm trying to factorize answers here.

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

> 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).
Right, I introduced an automatic versioned dependency in mandriva rpm
for this reason.

> 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.
Right, and it also support my point on distinguishing between retrieving
information, and testing it is accurate.

By why not try to compile and link for (c) instead of trusting
timestamps ? This is an higher-level check, and closer from the actual
problem moreover.

> [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.
Are you trying to compete with Java and PHP developper here ? Using
private code copies may make your (programmer) life easier, but just
make distribution package maintainers works more complex, as they have
to remove them and make sure your code build with system version.

That's a wrong solution to a real problem.

> 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 ?
It is precisely my point: is so much flexibility desirable ?

> 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)
I don't understand the interest of that specific point.

> plus other tools (ocamldep, ocamldoc, findlinb, etc).
This is the simplest model, which is also the more robust.

I have some proposal that seems quite simple to achieve:
- for each of those alternative, have AC_PROG_OCAML export two
variables, FOO and FOO_OPT
- by default, FOO would point to the same value as FOO_OPT if available
- a user switch would prevent this behaviour

So, the developper could enforce the use of only optimised versions, or
let the choice to the user with a correct default. Does it sounds good ?

> (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 :)
Ouch, it hurts...

We're just dealing with autoconf macros here (no automake support yet),
meaning developer still has to write the corresponding Makefile.
Providing users switches in those macros force the developper to handle
them. So, I'd rather keep uneeded complexity out, at least for the moment.

Allowing 3, 4 & 5 is possible with the following scheme, based on
AM_PROG_LIBTOOL:
- by default, AC_PROG_OCAML provides --enable-native and
--enable-bytecode switches, defaulting to true
- AC_DISABLE_OCMAL_NATIVE turns off the default value for --enable-native
- AC_DISABLE_OCMAL_BYTECODE turns off the default value for
--enable-bytecode
Those switches just set OCAML_BUILD_NATIVE and OCAML_BUILD_BYTECODE
variables.

>>> 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.
If there is an explicit list of platform/findlib versions known to be
broken, or a typical way to diagnose such problems, this ought to be
managed directly in the macro itself, with some kind of error message,
not through a user switch.

> 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.
But you don't need an explicit option for this: if you really want to be
findlib-independant, test with findlib installed and without findlib
installed.

My point is: don't put too much personal preferences in those shared
macros, especially as someone else will have to maintain them. They
should only bring a minimal number of consensual primitives, upon wich
developers may design their own build script that fit their own taste.

If you look at pkg-config, for instance, there is no AC_PROG_PKCONFIG
macro that automatically bring you a switch to disable its use. However,
PKG_CHECK_MODULE allows you to override pkg-config results automatically
each time you use it for a given library.

-- 
Guillaume Rousse
Projet Estime, INRIA
Domaine de Voluceau
Rocquencourt - B.P. 105
78153 Le Chesnay Cedex - France