Fixed typo: .mllist -> .mllib

[lindig]

Small typo in list of supported target extensions.

[gasche]

Did you intend to include the examples with them? They look fine; I wonder how to settle the threshold between "command-line options in the Makefile" and "stuff in _tags", maybe we should try to have examples in both styles.

[lindig]

On 16 Sep 2015, at 14:38, gasche notifications@github.com wrote:

Did you intend to include the examples with them? They look fine; I wonder how to settle the threshold between "command-line options in the Makefile" and "stuff in _tags", maybe we should try to have examples in both styles.

I did not intend to include them in the pull request since I just started and expect to tweak them more.

I think, the natural progression is: command line options, _tags, myocamlbuild.ml. Something that is likely to change from build to to build, like building for debugging and profiling is something I would keep out of _tags when possible as changing command line flags is easier than editing _tags. Otherwise, I’d put in all but the most basic projects flags in _tags.

— C

[gasche]

That seems very reasonable (I tend to prefer editing _tags than the Makefile, as it seems Makefiles actually grow more complex more often, but I think the progression you outline is probably more natural). Maybe bin_annot should migrate to tags as well (as I don't think it makes sense to disable it), at least as soon as there is a _tags file for some other reason.

[lindig]

I have moved bin_annot to _tags where a _tags file exists and added one more example. I initially didn't realise that my examples would end up in this pull request but would be fine if you would pull them all in. I have some more ideas for examples but maybe these prove useful and inspire more examples.

[gasche]

When sending a pull request from a head to another, all the commits not in common are submitted. The solution to avoid your problem is to create a different branch in your personal clone for each feature (those are called "feature branch"), eg. one branch by typo or one branch for examples.

There are two simple things that should be changed with the lex-yacc example:

• ocamlyacc is obsoleted by Menhir so I don't think we should advertise its use in any way, I would much prefer a Menhir example (luckily Menhir support most simple ocamlyacc grammars out of the box, so changing that should be very easy)
• I think you forgot to include the .mly file, at least the example seems to have no grammar

[lindig]

I've modified the example 05 to use Menhir. I'm a little wary to use tools outside the standard distribution for something like a manual, though.

I've also added a test target and check that tools like Menhir and packages are available to catch problems early.

[gasche]

Thanks! I have some minor cosmetic changes I'll do to the menhir grammar (using variables rather than $1), but I'll merge this as is and work from there.

[gasche]

So I merged your changes (all commits in your master branch; remember to do a feature branch for your next pull request!), and did a few changes to the last example. Thanks a lot for the examples!

[gasche]

I added an Examples section to the introduction, listing the examples you contributed. I'm a bit worried of people trying to use the examples without understanding the basic concepts of the tool (maybe I could list them somewhere later in the text to discourage this), but it also will be useful to users that have read parts of the documentation already and just want to bootstrap their project off something.

Of course there are still many kind of examples worth having. I will create an issue to discuss that.