[Caml-list] Ocamlcore.org: Discussions place, and requirements
Romain Beauxis
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
_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Sylvain Le Gall
> 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
Pietro Abate
> 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
Romain Beauxis
> 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