It uses external tools like OCamlbuild and it can be considered as the glue
between various subsystems that do the job.
It also features a do-it-yourself command line invocation and an internal
configure/install scheme. Libraries are managed through findlib. It has been
tested on GNU Linux and Windows.
It also allows to have standard entry points and description. It helps to
integrates your libraries and software with third parties tools like GODI.
Changelog and full blog post here:
http://www.ocamlcore.com/wp/2010/10/oasis-v02-release/
Homepage:
http://oasis.forge.ocamlcore.org/
Get source code:
$ darcs get http://darcs.ocamlcore.org/repos/oasis
Browse source code:
http://darcs.ocamlcore.org/cgi-bin/darcsweb.cgi?r=oasis;a=summary
[Generated by 'OASIS announce']
_______________________________________________
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
> OASIS generates a full configure, build and install system for your
> application. It starts with a simple `_oasis` file at the toplevel of your
> project and creates everything required.
Do you have plans to make GODI packages for Oasis and its dependencies?
(I don't mean using Oasis to automate the generation of GODI packages;
I mean GODI packages for Oasis itself). It's a little step that makes
trying out new software all the more convenient...
Cheers,
Dario Teixeira
I don't have plans for GODI, but I plan to build Debian packages. I don't
know (yet) GODI enough to do it. But I would help anyone who has plan
about that.
If you wan to try OASIS, there is an installer that should work out of
the box on Linux/Windows (just providing the application, not the
library). It is on the download page:
https://forge.ocamlcore.org/frs/?group_id=54
Regards,
Sylvain Le Gall
> Changelog and full blog post here:
> http://www.ocamlcore.com/wp/2010/10/oasis-v02-release/
I've used oasis for small experiments, and I hope this project will gain
traction.
I found it perhaps still a bit rough on the dev. side : it's heavier than
just writing a simple META file, but the benefits are important (in
particular, you can avoid autoconf but still be more flexible than a simple
Makefile-only build system), and it's particularly sweet on the user side.
I'm not convinced with the linux-installer.bin you distribute, and prefer to
build from source. oasis built flawlessly, but I first had to find the
various dependencies; in particular, the oUnit version required is newer
than the package available in either Godi or Debian, and your small
dependencies (odn, ocamlify...) cannot be found elsewhere. They're very easy
to build (thanks to... oasis), but the whole search-on-ocamlforge process is
perhaps unnecessary.
Could you provide an archive included the source of all those dependencies
that are not in both Debian (testing) and GODI ?
I'm currently using debian testing, and have needed the following files :
- ocaml-data-notation-0.0.3.tar.gz
- ocaml-expect-0.0.2.tar.gz
- ocamlify-0.0.1.tar.gz
- ounit-1.1.0.tar.gz
(Of course, Oasis-DB will make all that a breeze ;-)
It's a triviality to say but I'm quite happy with the change in command-line
invocation style (OASIS -setup => oasis setup). Four small comments
regarding this :
- when just typing "oasis", it would be nicer to directly give the help
page; darcs and git, for example, have this behavior that I find handy
- the small message we currently have says "[..] call 'oasis -help' for
help". Wouldn't it be more consistent to "call 'oasis help'" ? I can see
that you kept the -help/--help interface for compatibility with other
command-line tools, but the subcommand-style is more consistent with the
rest of the interface
- git and darcs automatically call a pager when producing long text output;
it would also be a nice thing to have in oasis, especially for the "oasis
manual"
- the current behavior of subcommand help ("oasis help query") output first
the general help, then the subcommand-specific help; I think just the
subcommand-specific help would be a better output
Thanks for the work !
Have you tried the "revamped" quickstart subcommand. I am trying to make
the creation of _oasis as easy as possible...
If you have any suggestions to help make "lighter", I'll be happy. BTW,
when you say "heavier", is it in term of complexity, of size of the
generated setup.ml or something else?
> I'm not convinced with the linux-installer.bin you distribute, and prefer to
> build from source. oasis built flawlessly, but I first had to find the
> various dependencies; in particular, the oUnit version required is newer
> than the package available in either Godi or Debian, and your small
> dependencies (odn, ocamlify...) cannot be found elsewhere. They're very easy
> to build (thanks to... oasis), but the whole search-on-ocamlforge process is
> perhaps unnecessary.
> Could you provide an archive included the source of all those dependencies
> that are not in both Debian (testing) and GODI ?
> I'm currently using debian testing, and have needed the following files :
> - ocaml-data-notation-0.0.3.tar.gz
> - ocaml-expect-0.0.2.tar.gz
> - ocamlify-0.0.1.tar.gz
> - ounit-1.1.0.tar.gz
>
> (Of course, Oasis-DB will make all that a breeze ;-)
And before OASIS-DB, there should be "oasis bundle", that should do
exactly what you ask me.
I can try to create an experimental oasis-bundle-0.2.0.tar.gz. Will you
test it?
>
>
> It's a triviality to say but I'm quite happy with the change in command-line
> invocation style (OASIS -setup => oasis setup). Four small comments
> regarding this :
>
> - when just typing "oasis", it would be nicer to directly give the help
> page; darcs and git, for example, have this behavior that I find handy
>
> - the small message we currently have says "[..] call 'oasis -help' for
> help". Wouldn't it be more consistent to "call 'oasis help'" ? I can see
> that you kept the -help/--help interface for compatibility with other
> command-line tools, but the subcommand-style is more consistent with the
> rest of the interface
>
> - git and darcs automatically call a pager when producing long text output;
> it would also be a nice thing to have in oasis, especially for the "oasis
> manual"
>
> - the current behavior of subcommand help ("oasis help query") output first
> the general help, then the subcommand-specific help; I think just the
> subcommand-specific help would be a better output
>
All this seems quite reasonable. May I ask you to submit feature
requests about this on the BTS?
Regards
Sylvain Le Gall
> Have you tried the "revamped" quickstart subcommand. I am trying to make
> the creation of _oasis as easy as possible...
>
>
> If you have any suggestions to help make "lighter", I'll be happy. BTW,
> when you say "heavier", is it in term of complexity, of size of the
> generated setup.ml or something else?
I think it's mostly a question of getting used to the new features of oasis.
Oasis much more things than with a META (configuration, compilation, etc.),
so the downside is that there are more things to specify in a _oasis file
than in a META file.
During my work with various such tools (Makefile, META, etc.), I found out
that I rely strongly on example files that I can copy/paste and
modify/adapt. With time I have accumulated some templates for
Makefile/META/_tags/myocamlbuild.ml covering my basics need, and I know
where to look for more advanced things to imitate. I have not yet
accumulated a comprehensive set of reusable _oasis files (though the
documentation is certainly in the good direction), but I think it's just a
matter of time.
And before OASIS-DB, there should be "oasis bundle", that should do
> exactly what you ask me.
>
> I can try to create an experimental oasis-bundle-0.2.0.tar.gz. Will you
> test it?
>
Certainly I'd be glad to give it a try.
> It's a triviality to say but I'm quite happy with the change in
> command-line
> > invocation style (OASIS -setup => oasis setup). Four small comments
> > regarding this : [..]
>
> All this seems quite reasonable. May I ask you to submit feature
> requests about this on the BTS?
>
>
Done.
Indeed.
> During my work with various such tools (Makefile, META, etc.), I found out
> that I rely strongly on example files that I can copy/paste and
> modify/adapt. With time I have accumulated some templates for
> Makefile/META/_tags/myocamlbuild.ml covering my basics need, and I know
> where to look for more advanced things to imitate. I have not yet
> accumulated a comprehensive set of reusable _oasis files (though the
> documentation is certainly in the good direction), but I think it's just a
> matter of time.
>
There are some examples linked from here:
http://oasis.forge.ocamlcore.org/documentation.html
And direct links to various other project that use OASIS in the real
life here:
http://oasis.forge.ocamlcore.org/alreadyusing.html
I will be happy to add your examples or projects there, if you
accumulate the same knowledge as with other tools.
>
> > It's a triviality to say but I'm quite happy with the change in
>> command-line
>> > invocation style (OASIS -setup => oasis setup). Four small comments
>> > regarding this : [..]
>>
>> All this seems quite reasonable. May I ask you to submit feature
>> requests about this on the BTS?
>>
>>
> Done.
>
Great, they will probably be in the 0.3.0 release.
Cheers,
Oh! Yeah! :-)
--
Architecte Informatique chez Blueline/Gulfsat:
Administration Systeme, Recherche & Developpement
+261 34 56 000 19
Hi,
I recently realized my first GODI package (godi-onotify).
As I intend to use OASIS for my future projects, I think I could find
some free time to package OASIS for GODI.
Regards,
Ludovic Stordeur