Custom option

[jlaurens]

Actually, custom options are documented but not supported.
This PR fixes this problem.

New options must be declared prior to parsing the arguments, it is now done in a new preparation script name build-pre.lua near build.lua eventually loaded by l3build-arguments.lua.

New global function declare_option(⟨name ⟩,⟨table ⟩) is used to declare a new option whereas update_option(⟨name ⟩,⟨other table ⟩,⟨provide ⟩) is used to update option data. Both validate their arguments.

Testing is not very well designed and should be integrated in the check target process, a forthcoming feature.

[josephwright]

This all looks rather baroque: I am wondering if the best plan is simply to rule out custom options, which don't really work with the structure as it is now (they might have done in the older approach).

[davidcarlisle]

I don't think there is really any need for custom options, there are enough option names for any particular project and in practice enough hooks that a package needing some custom code can redefine one of the existing options to run whatever code is needed. Or if something really new comes up a package author could make a PR to add a new option to the base l3build code.

[FrankMittelbach]

agreed, this is a leftover approach and should be dropped from the documentation rather than implemented.

[josephwright]

Ok, so the consensus is to drop the idea from the docs. I’ll leave the PR open until I can do that.