Skip to content
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.

Sign up for GitHub

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

Jump to bottom

--help doesn't work #136

Open
UnixJunkie opened this issue Jun 1, 2015 · 2 comments
Open

--help doesn't work #136

UnixJunkie opened this issue Jun 1, 2015 · 2 comments
Labels
enhancement feature request

Comments

@UnixJunkie
Copy link

this was reported to me by @thizanne
@UnixJunkie
Copy link
Author

I guess that's because obuild doesn't use Arg from the stdlib.

@UnixJunkie
Copy link
Author

but @thizanne being a great open source hacker, he might add this cool feature

ptoscano added a commit to ptoscano/obuild that referenced this issue Sep 10, 2018
@ptoscano
obuild: refactor handling of commands and options
d097149 
The current system mixes manual command line parsing for global options,
and the Arg module for command options, which is not optimal:
- no way to generate the list of global command line options, nor to
  document them
- the per-command options are used only when parsing, so showing them
  for help is not possible
- two different ways to parse options

Also, the handling of commands themselves is messy:
- all of them are implemented in the same module, overloading it with
  different tasks
- their help texts are structured in lists of lines, and with a separate
  list to maintain
- the names of the commands are hardcoded in a couple of places

To overcome this situation, create a small Cmd module to represent a
single command, with all the information stored there: name, options,
help texts, and the actual function for it.  Split all the commands in
own modules named Cmd_<command>, which contains only the command
declaration, its function, and all the helper stuff for it.
Consequently refactor the command line handling: use the dynamic parsing
feature of Arg, so the global command line options (which are now
converted to Arg) are parsed first, and then the command options are
parsed.

The results are various:
- each command is in its own modules, with its options clearly
  represented, and help texts side with them
- global command line options are parsed properly
- main.ml is very small, way more readable, and will almost require no
  changes for adding new commands (see drawback below)
- the 'help' command had to be basically rewritten due to the
  refactoring; OTOH, `obuild help <command>` works fine now
- `obuild --help` works fine now (fixes ocaml-obuild#136)

The only drawback is that, due to the way obuild is built using obuild,
the modules of the commands are not built if nothing references them.
As result, just open them all in main.ml.
@ptoscano ptoscano mentioned this issue Sep 10, 2018
Closed
ptoscano added a commit to ptoscano/obuild that referenced this issue Sep 12, 2018
@ptoscano
obuild: refactor handling of commands and options
9f258ad 
The current system mixes manual command line parsing for global options,
and the Arg module for command options, which is not optimal:
- no way to generate the list of global command line options, nor to
  document them
- the per-command options are used only when parsing, so showing them
  for help is not possible
- two different ways to parse options

Also, the handling of commands themselves is messy:
- all of them are implemented in the same module, overloading it with
  different tasks
- their help texts are structured in lists of lines, and with a separate
  list to maintain
- the names of the commands are hardcoded in a couple of places

To overcome this situation, create a small Cmd module to represent a
single command, with all the information stored there: name, options,
help texts, and the actual function for it.  Split all the commands in
own modules named Cmd_<command>, which contains only the command
declaration, its function, and all the helper stuff for it.
Consequently refactor the command line handling: use the dynamic parsing
feature of Arg, so the global command line options (which are now
converted to Arg) are parsed first, and then the command options are
parsed.

The results are various:
- each command is in its own modules, with its options clearly
  represented, and help texts side with them
- global command line options are parsed properly
- main.ml is very small, way more readable, and will almost require no
  changes for adding new commands (see drawback below)
- the 'help' command had to be basically rewritten due to the
  refactoring; OTOH, `obuild help <command>` works fine now
- `obuild --help` works fine now (fixes ocaml-obuild#136)

The only drawback is that, due to the way obuild is built using obuild,
the modules of the commands are not built if nothing references them.
As result, create no-op aliases for all of them in main.ml.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement feature request
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

RFC: obuild: refactor handling of commands and options ptoscano/obuild
1 participant
@UnixJunkie