Re: [Caml-list] Re: working %.pp.ml target with ocamfind/ocamlbuild

[Wojciech Meyer <wojciech.meyer@googlemail.com>]

>> - it's dead easy to build a single file, without constructing
>> horrendous command line or adding an unneeded target
>
>
> Come on, this is not a fair critique. Have you ever started a fresh omake
> project? It's really short:
>
> .DEFAULT: $(OCamlProgram put_here_the_name_of_your_program, module1 module2
> ...)

Yes, right, but still you have to write a special rule and change
file, instead of requesting this to be built straight from a comfort
of shell.
So the state is involved, you can perhaps do that with some --eval
sort of thing.
For instance, sometimes I really want to experiment and build a single
module without any plans to integrate it, then ocamlbuild is
appropriate for that job.
BTW: Have you tried out of tree builds? This works out of the box and
by default with ocamlbuild, and AFAIR I couldn't understand how to do
this in OMake.

>> - it's declarative, you don't want to construct tons of special
>> variables and concatate them
>
>
> You can have pattern rules in omake, and I think they are a full replacement
> for tags.

Need to look at it!

> I'd recomment it already when the alternative is to write ocamlbuild plugins
> (which are the biggest error of ocamlbuild - ocaml is just not the right
> language to modify the behavior of builds).

In fact I fully agree that DSLs are way better in some respects than
full blown and turing complete languages.
In this case it's just easy to analyze the rules, however here you
*have also* a  DSL too, just embedded in the plugin.
OCamlbuild have very simple and clean interface to deal with the
essential properties of the tree like dependencies, shell commands
etc.
So in fact the plugin is a meta program that *generates* instances of
these rules, in a spirit of ML.
So I disagree that this is a bottleneck, you have extra syntactical
verbosity but usually it's a minor problem.
OTOH you can factor out easily the patterns. Of course this comes with
a risk of user being in full control of the build system, and then
it's not easy to explain what to do and what not to do.

>> Both however suffer from almost similar problem - OMake is a bit
>> underused for the quality you get, where ocamlbuild is just underrated
>> for the ideas it has.
>
>
> ocamlbuild certainly has some nice ideas, but I'd overall say that it jumps
> too short. It's ok for student projects, and I guess this is the main
> justification for having it in the distribution. It's easier than
> traditional Makefiles. What's missing is that you cannot easily modify
> existing behavior, and to my mind, plugins do not use the right
> abstractions. A one-liner in omake's DSL (which is actually a nice
> dynamically-typed functional language) turns into a lengthy phrase.

> Well, there are also things I don't like in omake (e.g. environments are
> powerful but also difficult to debug). But so far it is the clear winner for
> me, mostly because it has a good DSL which is more adequate than
> ocamlbuild's attempt to reuse ocaml for build purposes.

I'm mostly buying your argument about the DSL, however as I said
ocamlbuild has it too and just not on a syntactic level.

> Gerd

Wojciech

>
>
>
>> --
>> Wojciech
>>
>> On Tue, Sep 11, 2012 at 1:27 PM, Gerd Stolpmann <info@gerd-stolpmann.de>
>> wrote:
>> > Am 10.09.2012 14:18:42 schrieb(en) bob zhang:
>> >>
>> >> Btw, there's something wrong with the rule "%.pp.ml", I don't remember
>> >>
>> >> exactly where it's, for your interest, you can have a look at
>> >>
>> >>
>> >> https://bitbucket.org/HongboZhang/camlp4/src/e88f431db722/myocamlbuild.ml
>> >>
>> >> ocaml has a really really *high quality* compiler, but all the tools
>> >> around
>> >> it is not that satisfied, contribution is much harder than bug fixes
>> >> :-(
>> >>
>> >> If you take a look at ICFP 12's paper about Shake, the idea is
>> >> essentially
>> >> the same as 'ocamlbuild', and the idea is cool, but the implementation
>> >> of
>> >> ocamlbuild is fragile and buggy.
>> >
>> >
>> > And I wonder why ocamlbuild is actually used. There is a *high quality*
>> > build tool for ocaml: omake.
>> >
>> >
>> >>
>> >> On Mon, Sep 10, 2012 at 2:08 PM, Hongbo Zhang
>> >> <bobzhang1988@gmail.com>wrote:
>> >>
>> >> > Greetings,
>> >> > On 9/9/12 6:29 PM, Wojciech Meyer wrote:
>> >> >
>> >> >> Gabriel Scherer <gabriel.scherer@gmail.com> writes:
>> >> >>
>> >> >>  This is useful for debugging purposes, and for some (minor) modes
>> >> >> of
>> >> >>> use of Camlp4. However, for most Camlp4 development, this has the
>> >> >>> severe downside of losing the location information of the original
>> >> >>> file, if I understand correctly. This means that you don't want to
>> >> >>> use
>> >> >>> it as a transparent step towards compilation, but only in
>> >> >>> exceptional
>> >> >>> situations where the developers will re-edit the output code.
>> >> >>>
>> >> >>
>> >> >> I think I've to say I disagree it's not useful, when I'm developing
>> >> >> a
>> >> >> syntax extension on top of Camlp4 I really want to see the generated
>> >> >> code. Moreover to understand some of the more complicated syntax
>> >> >> extensions like type_conv, deriving, FoldGenerator I need to look at
>> >> >> the
>> >> >> expanded code to understand how to use it - last time I hit the same
>> >> >>
>> >> > Yes, it's damn useful not only for bootstrapping, but also for
>> >> > developing
>> >> > to locate type errors. But there's something wrong with Camlp4's
>> >> > printer,
>> >> > it has *4* printers in total, writing a printer for an Ast which has
>> >> > no
>> >> > backend is totally useless. In my branch of camlp4, *I removed all
>> >> > those
>> >> > 4
>> >> > printers and using tools/pprintast.ml* in ocaml's compiler source
>> >> > tree(with some my own bug fixes), and it works very well.
>> >> > Btw, are you in ICFP? we could have a talk about Camlp4 :-)
>> >> >
>> >> >> problem it was actually 'deriving-ocsigen' when I needed to
>> >> >> implement
>> >> >> my
>> >> >> own Show module - it's just much faster to see what's being
>> >> >> generated
>> >> >> for the usual case, then trying to figure out from the recipe in the
>> >> >> documentation.  Otherwise for bootstrapping purposes, you might want
>> >> >> to
>> >> >> pre-generate some code too and put into the repository.
>> >> >>
>> >> >> --
>> >> >> Wojciech Meyer
>> >> >> http://danmey.org
>> >> >>
>> >> >>
>> >> >
>> >>
>> >>
>> >> --
>> >> Regards
>> >> -- Bob
>> >>
>> >> --
>> >> Caml-list mailing list.  Subscription management and archives:
>> >> https://sympa-roc.inria.fr/wws/info/caml-list
>> >> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>> >> Bug reports: http://caml.inria.fr/bin/caml-bugs
>> >>
>> >>
>> >
>> > --
>> > ------------------------------------------------------------
>> > Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
>> > Creator of GODI and camlcity.org.
>> > Contact details:        http://www.camlcity.org/contact.html
>> > Company homepage:       http://www.gerd-stolpmann.de
>> > ------------------------------------------------------------
>> >
>> > --
>> > Caml-list mailing list.  Subscription management and archives:
>> > https://sympa-roc.inria.fr/wws/info/caml-list
>> > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>> > Bug reports: http://caml.inria.fr/bin/caml-bugs
>> >
>>
>> --
>> Caml-list mailing list.  Subscription management and archives:
>> https://sympa-roc.inria.fr/wws/info/caml-list
>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>> Bug reports: http://caml.inria.fr/bin/caml-bugs
>>
>>
>>
>