Allow base override with --with-base-lang= parameter

[jordikroon]

Adds a --standalone configure option that treats the language directory as a complete, authoritative manual tree instead of a translation overlay of en.

This continues the third-party manual work from #324. And is required for building doc-extensions, without forcing the in/output to en.

[jordikroon]

Added this because it was a stale variable.

[alfsb]

This variable can be removed, and --chmonly skiped as legacy parameter. This script now always generate all paths.

[jordikroon]

The previous line was a bug. It contained an extra space.

[alfsb]

God catch.

[alfsb]

The objective is building doc-ext with --with-lang=contrib --standalone?

For first building doc-ext, that only exists in English, cloning the doc-ext/doc-contrib as en/ suffices.

---

In general I'm trying to remove the options of configure.php. I was about to remove xpointer-reporting and some other cases. Also, I was normalizing code paths to consider building a "single language" versus "double languages" (aka, base overlay + translation overlay) as text-entities.php does now, by accepting up to two language arguments, in overwriting order. But configure.php has a long history of building doc-en as en when without parameters, and adding a translations overlay with --with-lang=.

Then, the suggestion would be renaming --standalone to something like --with-single-lang=, so codepath that forces configure into building a single language that is not a en dir happens at one place. And $ac can receive an extra key, "LANGS", that enumerate all the lang dirs in consideration, in overwrite order (last wins), so the test of is base turns into is_single_language.

$ac["LANG"] and $ac["LANGS"][] is initialized with en, --with-lang= replaces the first and add in the second, --with-single-lang= replaces both first and second.

That will make condigure.php align with text-entities.php (and unlike some other sub parts).

[jordikroon]

The objective is building doc-ext with --with-lang=contrib --standalone?

For first building doc-ext, that only exists in English, cloning the doc-ext/doc-contrib as en/ suffices.

And how do you see this from a server or local perspective where both doc-en and doc-extensions need to be?
What you are implying is that they both need "en" as its output. Which if I am correct will conflict with each other when doc-web tries to load them.

Locally docker may be the solution, but I like the ability to just run configure.php myself when required.

In general I'm trying to remove the options of configure.php. I was about to remove xpointer-reporting and some other cases. Also, I was normalizing code paths to consider building a "single language" versus "double languages" (aka, base overlay + translation overlay) as text-entities.php does now, by accepting up to two language arguments, in overwriting order. But configure.php has a long history of building doc-en as en when without parameters, and adding a translations overlay with --with-lang=.

Then, the suggestion would be renaming --standalone to something like --with-single-lang=, so codepath that forces configure into building a single language that is not a en dir happens at one place. And $ac can receive an extra key, "LANGS", that enumerate all the lang dirs in consideration, in overwrite order (last wins), so the test of is base turns into is_single_language.

$ac["LANG"] and $ac["LANGS"][] is initialized with en, --with-lang= replaces the first and add in the second, --with-single-lang= replaces both first and second.

That will make condigure.php align with text-entities.php (and unlike some other sub parts).

Technically doc-en is standalone in its sense that it doesn't depend on any other language. What if we rename --with-single-lang to --with-base-lang which will default to en. doc-extensions can then set this --with-base-lang=extensions. It could behave kind of the same as what the hardcoded en references do at this very moment.
And optionally it will allow translations from a different base.

[alfsb]

And how do you see this from a server or local perspective where both doc-en and doc-extensions need to be? What you are implying is that they both need "en" as its output. Which if I am correct will conflict with each other when doc-web tries to load them.

I was only considering the building of each one, separately. As they need to be fully independent, they do not need to exist side by side at any moment. And yes, not changing the en-as-base restriction then would be necessary to clone doc-base in two separate dirs. A change like this would avoid the duplication of doc-base.

Note, whorever, that "en" as output is not really a problem, AFAIK the actual building of manuals resuses doc-base and PhD output dirs, collecting the generated artifacts after the end of each language.

Technically doc-en is standalone in its sense that it doesn't depend on any other language. What if we rename --with-single-lang to --with-base-lang which will default to en. doc-extensions can then set this --with-base-lang=extensions. It could behave kind of the same as what the hardcoded en references do at this very moment. And optionally it will allow translations from a different base.

That would be very ok, as this align the base-as-single pattern of actual configure. EN_DIR probably would end something like LANG_BASE or LANG_BASE_DIR.

[jordikroon]

Feedback has been handled. Please let me know what you think.