Ocamlcore.org: Discussions place, and requirements

Ocamlcore.org: Discussions place, and requirements

[Romain Beauxis]

	Hi all !

I have two question related to the recent discussions around ocaml community.

First of all, I'd like to know if we should continu discussing here, or we 
better switch to a new mailing list.

There's a mailman almost ready on ocamlcore.org, so perhaps it should be 
better to continue on a mailing list there ?


Second questions is ocaml modules that we are going to distribute there.
While we have discussed that different way we could use to collect projects 
from different places, I don't think we discussed the minimal support that 
the module should provide when it comes to installing and registering the 
module.

For instance, all perl modules on CPAN share a common build and install 
system, the same for PHP pear and etc..

This can be a real trouble sometimes, like for the xml-light parser: while it 
does not support ocamlfind, the debian package added it, which I think is 
fine. But, our configure script detects xml-light based on ocamlfind, so it 
is screwed up when users want to build the software but installed xml-ligth 
from upstream tarball...

I would recommend that we agreee on a minimal support the a module should ship 
to be part of ocamlcore.org. 

My point would be that it should provide a META file that should work with 
ocamlfind.
Others might have a better idea, but it would be nice to choose something, 
don't you think ?

Then, we should also provide templates for doing so. We have templates for 
configure+ocamlfind which works for all our bindings...



Romain 

Re: Ocamlcore.org: Discussions place, and requirements

[Sylvain Le Gall]

On 01-02-2008, Romain Beauxis <toots@rastageeks.org> wrote:
> 	Hi all !
>
> I have two question related to the recent discussions around ocaml community.
>
> First of all, I'd like to know if we should continu discussing here, or we 
> better switch to a new mailing list.
>
> There's a mailman almost ready on ocamlcore.org, so perhaps it should be 
> better to continue on a mailing list there ?
>

Mail system is not enough tested to let people use it for now. I hope it
will be fixed soon, but we have to do some extended checking before
announcing on a public mailing list the availability of ocamlcore.org!

>
> Second questions is ocaml modules that we are going to distribute there.

I think your question worth to be asked, but i don't think it is related
to ocamlcore.org.

The forge hosted at this location will be for all ocaml related project.
I don't think we will enforce the use of any particular build system. In
the future, we can set up another system to centralize modules -- like a
CPAN for ocaml. But this is another topic (i.e we should take time to
build something strong). 

Regards,
Sylvain Le Gall

Re: [Caml-list] Ocamlcore.org: Discussions place, and requirements

[Pietro Abate]

On Fri, Feb 01, 2008 at 01:36:09PM +0100, Romain Beauxis wrote:
> Second questions is ocaml modules that we are going to distribute there.
> While we have discussed that different way we could use to collect projects 
> from different places, I don't think we discussed the minimal support that 
> the module should provide when it comes to installing and registering the 
> module.

I think that for the moment it's useless to strive to convert every and
each ocaml developer to use the same build system. As I suggested
before, what we should do is only to agree to an interface and then let
the various distribution to deal with build dependencies. In your
example, if a library don't use ocamlfind, this is ok. The only
important thing is to honor the build interface. 

As a developer (and as a software maintainer) I imagine a world where if
I want to use library x.y I've only to take care to give it the right
tools to build, but with the assurance that if I call 'make install',
the library will end up in the right place. Ocamlcore.org would contain
all these libraries so fetching a new version from the net and
re-compiling it would be a snap.

One day we could hope for a convergence in the building tool department
as well, but I think is far too early to call for this kind of
standardization. For example it would be great if all developers would
integrate the debian patches to their build systems...

pietro

-- 
++ 
++ "All great truths begin as blasphemies." -George Bernard Shaw
++ Please avoid sending me Word or PowerPoint attachments.
   See http://www.gnu.org/philosophy/no-word-attachments.html

Re: [Caml-list] Ocamlcore.org: Discussions place, and requirements

[Romain Beauxis]

Le Friday 01 February 2008 14:27:23 Pietro Abate, vous avez écrit :
> On Fri, Feb 01, 2008 at 01:36:09PM +0100, Romain Beauxis wrote:
> > Second questions is ocaml modules that we are going to distribute there.
> > While we have discussed that different way we could use to collect
> > projects from different places, I don't think we discussed the minimal
> > support that the module should provide when it comes to installing and
> > registering the module.
>
> I think that for the moment it's useless to strive to convert every and
> each ocaml developer to use the same build system. As I suggested
> before, what we should do is only to agree to an interface and then let
> the various distribution to deal with build dependencies. In your
> example, if a library don't use ocamlfind, this is ok. The only
> important thing is to honor the build interface.
>
> As a developer (and as a software maintainer) I imagine a world where if
> I want to use library x.y I've only to take care to give it the right
> tools to build, but with the assurance that if I call 'make install',
> the library will end up in the right place. Ocamlcore.org would contain
> all these libraries so fetching a new version from the net and
> re-compiling it would be a snap.
>
> One day we could hope for a convergence in the building tool department
> as well, but I think is far too early to call for this kind of
> standardization. For example it would be great if all developers would
> integrate the debian patches to their build systems...

I'm completly agnostic on the tool used and I agree that it should be more an 
issue of a common interface.

The other needs I was expressing where:
 * Standard location for installation
 * Standard way to check if a system can provide build environment for a given 
module, for compilation checks and build in projects using the module.


Romain