[build2] build2 Module for CLI

[markus.pawellek at mailbox.org]

Per Edin <per.edin at sequence-point.se> via users <users at build2.org> 
wrote:

 > You can find a nice example of using build2/cli in the ODB code, 
here: https://git.codesynthesis.com/cgit/odb/odb/tree/odb/buildfile

Thank you!
Boris Kolpackov <boris at codesynthesis.com> wrote:

> Yes, pretty much.
> 
> If you plan to include .cli files from other .cli files, then you
> would probably want to add the dynamic dependency extraction via
> depdb-dyndep so that you don't have to track who depends on whom
> manually (similar to how you don't want to do this for C/C++
> headers):
> 
> https://build2.org/release/0.15.0.xhtml#dyndep
> 
> Another feature that you may want to take advantage of is the
> ability to define explicit target groups in buildfiles:
> 
> https://build2.org/release/0.16.0.xhtml#explicit-groups
> 
> But that's optional and is probably not worth the trouble if
> you have only a few .cli files.

Thank you for the tips and references.
Nice to know that I haven't been on the wrong path, here.
Your recommendations and additions sound good to me
and I will definitely look into this a little more.

>> The answer to this is somewhat complicated:
> 
> 1. Firstly, yes, there is a `cli` build2 module. It is currently part
>    of the build2 core because, as you correctly pointed out, build2
>    itself uses CLI. But we plan to change that, potentially in the
>    next release.
> 
> 2. Secondly, yes, it's definitely possible to create a "proper" (as
>    in, not bundled with the build2 core) module for CLI. However,
>    there is potentially another option as alluded to here:
> 
>    https://build2.org/release/0.16.0.xhtml#buildfile-import
> 
>    Specifically, with explicit groups, depdb-dyndep, and ad hoc
>    pattern rules, there isn't much in the current `cli` module
>    that you cannot do in a buildfile. So instead of writing a
>    build system module we may decide to just provide a buildfile
>    fragment with the CLI compiler which can then be imported by
>    projects that wish to compile .cli file. This has a number of
>    benefits compared to writing the build system module:
> 
>    a) We can use higher-level mechanisms to implement and maintain
>       this. While a build system module written in C++ has the
>       ultimate power and flexibility, it is also quite a bit of
>       work.
> 
>    b) We can bundle the rule with the CLI compiler package itself,
>       which means users will have one less thing to depend on and
>       build.
> 
> Based on that, the future of the `cli` build2 module is a bit
> uncertain: we may unbundle it from the build2 core or we may
> replace it with rules bundled with the CLI compiler. Or maybe
> a combination of the two. Specifically, besides generating the
> options parsing code, CLI also generates documentation, and
> this can get quite hairy and may actually require us to stick
> with the build system module. But that's still unclear and
> requires more thinking. As a result, I would suggest that you
> don't use the `cli` module for now.

Also thank you for this thorough explanation.
That is quite a lot to think about and I understand your suggestion.
Though, it is a pity to not use it ;)
Please, keep us/me up to date on its future.