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: skaller <skaller@u...>
Subject: Re: [Caml-list] Re: ocaml support in autotools
On Fri, 2006-08-04 at 14:48 +0200, Stefano Zacchiroli wrote:
> On Fri, Aug 04, 2006 at 03:32:26PM +1000, skaller wrote:
> > BTW: anyone working on this should examine the Debian Ocaml Policy.
> > Sorry no link off hand, ask on
> 
> The policy is available on line at this URL:
> 
>   http://pkg-ocaml-maint.alioth.debian.org/ocaml_packaging_policy.html/index.html

Thanks..

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

[]

> Still, I don't see the relationship of the policy with ocaml autotools
> support. 

I mention the policy document because it provides context which
may help factor autotools macros/variables etc.

There is a relationship: Debian packagers have to deal with
people's build systems.

> You may want to perform such a check at configure time, to ensure that
> linking will succeed, but IMO it would be overkilling and not really
> needed. After all the target user of autotools is a developer, not the
> final user. 

That's fine when everything works.. the problem comes when
something goes wrong. Then the person with the error is going
to try all sorts of things to solve the problem .. using
the latest cvs/svn repository version for example .. which
typically only have the autotools original sources, not
the generated scripts.

Perhaps not on Debian or GODI .. but it is common for Ocaml 
programmers to get inconsistent libraries simply because there's
no way to keep track of what libraries you have -- happens
to me all the time when I upgrade (in fact, its a bug in 
the Ocaml install procedure itself .. it doesn't properly
clean out the installation target)

So maybe a trial link is overkill .. when it succeeds:
it might be useful is it fails though.

In any case, this kind of thing is precisely what configuration
scripts actually do. Autoconf generated script regularly
compiles, links, and even runs C programs .. and so does
my Python hosted config script. For example we had some
code failing and it turned out our test of Linux epoll
was faulty. We just tried to compile a file using
create_epoll() but that compiles and links on Linux 2.4 kernels..
it doesn't work though. You actually have to executed the function
and check it doesn't return -1 to know if you have epoll support.

Exactly how one would do this in a cross compilation environment
I don't know (Felix is a cross-cross compiler). 

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