-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixed typo: .mllist -> .mllib #13
Conversation
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 |
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 |
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 |
I have moved |
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:
|
Examples now a have a test target. To make automated testing easier I rewrote some examples to take input from stdin intead from a file. A sanity target checks for the presence of packages and tools that are not part of the OCaml standard distribution to catch problems early.
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. |
Thanks! I have some minor cosmetic changes I'll do to the menhir grammar (using variables rather than |
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! |
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. |
Small typo in list of supported target extensions.