[build2] build2 Module for CLI

[Boris Kolpackov]

Markus Pawellek via users <users at build2.org> writes:

> As a more general approach, I then used a regex-based ad hoc recipe in the
> 'root.build' file.

Minor nit: those are called rules (a recipe is for a specific target, a
rule is for multiple targets, normally that match some pattern). I see
you correctly called it a rule in the comment below.


> Would this be the way to go?

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.

> Furthermore, thinking of the `in` module of build2 and the ability to
> create custom modules, is there already a build2 module for CLI that
> I might have overseen?
>
> Otherwise, would it even be possible to create a build2 module for CLI?
> I think build2 depends on CLI, doesn't it?

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.