Re: on mr 28 run locally.

Patrick Callahan <[email protected]> Sun, 26 Jul 2026 20:43:41 -0400
Newsgroups gmane.games.flightgear.devel
Message-ID <CACt=GQofj8NfYbVc9poCxKJ2=6kMYfx1-kO07sSsUbsstf0X2g@mail.gmail.com>
--===============1375910244741970815==
Content-Type: multipart/alternative; boundary="000000000000aed8f906578d05cc"

--000000000000aed8f906578d05cc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Short answer:

src/reference/cpp-api/translations/classes/DefaultTranslationParser.rst
and src/reference/cpp-api/translations/classes/TranslationDomain.rst:

have begun to fail when a local build of main is done on an empty build
directory.
due to the classes they reference being in the flightgear namespace in the
corresponding cxx files.

They do not fail during CI, even though the gitlab-ci.yaml specifies the
same sphinx command with --fail-on-warnin

Is there some caching preventing a failure in CI?

flightgear/src/Translations/DefaultTranslationParser.cxx
and flightgear/src/Translations/TranslationDomain.cxx

both declare namespace flightgear for the classes they contain.
The other translation modules do not declare flightgear as a namespace.

To correct this will take a merge request for the two .rst files adding
flightgear::

I can easily do that if you wish.

-Pat

The TLDR:
On Sun, Jul 26, 2026 at 2:46=E2=80=AFPM Florent Rougon via Flightgear-devel=
 <
[email protected]> wrote:

> Hi,
>
> Le 26/07/2026, Patrick Callahan <[email protected]> a =C3=A9crit:
>
> >
> /owc/worktrees/fgdocs.docs-12-http/src/reference/cpp-api/translations/cla=
sses/DefaultTranslationParser.rst:4:
> > WARNING: doxygenclass: Cannot find class "DefaultTranslationParser" in
> > doxygen xml output for project "flightgear" from directory:
> > ../Doxygen-output/flightgear/xml [docutils]
> >
> /owc/worktrees/fgdocs.docs-12-http/src/reference/cpp-api/translations/cla=
sses/TranslationDomain.rst:4:
> > WARNING: doxygenclass: Cannot find class "TranslationDomain" in doxygen
> xml
> > output for project "flightgear" from directory:
> > ../Doxygen-output/flightgear/xml [docutils]
> >
> > Am I missing something?
>
> You need the following directories at the same level:
>
>   simgear              (next branch)
>   flightgear           (ditto)
>   documentation
>
> Yep, I have those.  simgear and flightgear are symlinks in the same dir a=
s
documentation, although the actual names are fgdocs.docs-12-http and
fgdocs.main.
I pretty much followed the documentation on this and the directions are
correct.

Then, as done in the .gitlab-ci.yml, you need to run Doxygen from the
> 'documentation' directory:
>

Exactly.  my build script runs just build in the right worktree for main
and my  branch.


>   cd documentation
>   doxygen Doxygen-configs/simgear.Doxyfile      # or if you use 'just':
>   doxygen Doxygen-configs/flightgear.Doxyfile   # 'just doxygen'
>
>
Done that, but still get the warnings.

just build does the Doxygen as its first step. - no need for a separate ste=
p


> This doesn't need to be done often, unless you're documenting a moving
> target in the C++ codebase. The commands should create 'flightgear' and
> 'simgear' subdirs in 'Doxygen-output'.
>

right.  most of the time i run the uv script for sphinx.

The problem arises when I get ready to deliver to my fork and want to do a
full build and pre-commit before running.

1. Blow away the documentation output
2. make sure everything is staged
3. just build
4. just run -- this works even if just build failed.
5. pre-commit This passes if I haven't messed with line endings, spelling
etc.
6 push to callahanpa


The problem items are DefaultTranslationParser.cxx and
TranslationDomain.cxx, both of which declare the namespace as flightgear
{},
while neither reference the namespace in the .rst files.

The other translation .cxx files do not declare inside namespace
flightgear{}

This is a warning message in Sphinx, but if you run Just Build on an empty
build dir

 uv run sphinx-build --fail-on-warning -b html ./src ./build

will show a failure due to warning errors.  Everything is still build but
the procedure returns as an error.

If you remove the sphinx output and regenerate it locally, you should see
the same warning errors on build


gitlab-ci.yml does exactly the same as just build.  Can you confirm for me
that the results are cached between CI jobs?


> Joshua wrote the original README.md[1] which gives a normally easy way
> to install these dependencies using the 'uv' tool. This is what the CI
> uses, so it should definitely work. Note that this 'uv' way downloads
> and installs (in your user account) Python binaries from [2] as
> explained at [3] (I'm not a big fan of this).
>

I'd just as soon use it unless there are some known security reasons not to=
.


>
> If you're comfortable switching from the default 'uv' behaviour, there
> is a way to use a suitable Python installation of yours, though:
>   - don't run 'uv python install' (thus nothing that runs 'just init');
>   - put the following two lines in ~/.config/uv/uv.toml:
>
> #
> https://docs.astral.sh/uv/concepts/python-versions/#adjusting-python-vers=
ion-preferences
> python-preference
> <https://docs.astral.sh/uv/concepts/python-versions/#adjusting-python-ver=
sion-preferencespython-preference>
> =3D "only-system"
>
> Finally, it's possible to install the dependencies without 'uv' (and
> this is what I'm most used to by far, so I can help more easily in
> principle, however this is more =E2=80=9Cmanual=E2=80=9D and there are to=
ns of possible
> variations, which makes it difficult to document):
>
> - install a suitable Python (e.g., using a distro package or the
>   official installer);
> - create a venv as explained in the fgmeta-python README.md[4] (non-pipx
>   way) and install the aforementioned dependencies with the venv's pip
>   executable;
> - run sphinx-build from the venv (e.g., .venv/bin/sphinx-build, or use
>   the =E2=80=9Cactivate=E2=80=9D method).
>
>

> Whenever you install packages using 'pip' (or 'npm', for that matter),
> make 100% sure you correctly enter the package names (copy/paste them if
> unsure). Malware authors love =E2=80=9Ctypo-squatting=E2=80=9D: they uplo=
ad malware
> under names that are close to those of well-known packages, or names
> that match some trendy concept, or (Progress) names that AI chatbots
> =E2=80=9Chelpfully=E2=80=9D suggest.
>
>  That's good to know. Thanks.

Never trust an AI. They can be real nimnulls.

Also manually managing a bunch of npm stuff never seemed to me to be a good
idea.  Who knows were that stuff comes from.

Regards

Pat

--000000000000aed8f906578d05cc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Short answer:</div><div dir=3D"ltr"><br><=
/div><div dir=3D"ltr"><div>src/reference/cpp-api/translations/classes/Defau=
ltTranslationParser.rst</div><div>and=C2=A0<span style=3D"background-color:=
transparent">src/reference/cpp-api/</span><span style=3D"background-color:t=
ransparent">translations/classes/</span><span style=3D"background-color:tra=
nsparent">TranslationDomain.rst:</span></div></div><div><br></div>have begu=
n to fail when a local build of main is done on an empty build directory.<d=
iv>due to the classes they reference being in the flightgear namespace in t=
he=C2=A0</div><div><div>corresponding cxx files.</div><div><br></div><div>T=
hey do not fail during CI, even though the gitlab-ci.yaml specifies the sam=
e sphinx command with --<span aria-invalid=3D"spelling" class=3D"LI ng" sty=
le=3D"border-style:none;background:none">fail-on-warnin</span></div><div><s=
pan style=3D"background-color:transparent"><br></span></div><div><span styl=
e=3D"background-color:transparent">Is there some caching preventing a failu=
re in CI?</span></div><div><span style=3D"background-color:transparent"><br=
></span></div><div>flightgear/src/Translations/DefaultTranslationParser.cxx=
</div><div>and=C2=A0<span style=3D"background-color:transparent">flightgear=
/src/Translations/TranslationDomain.cxx</span></div><div><br></div><div>bot=
h declare namespace flightgear for the classes they contain.</div><div>The =
other translation modules do not declare flightgear as a namespace.</div><d=
iv><br></div><div>To correct this will take a merge request for the two .rs=
t files adding flightgear::=C2=A0</div><div><br></div><div>I can easily do =
that if you wish.</div><div><br></div><div>-Pat</div><div><br></div><div>Th=
e TLDR:</div><div><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmai=
l_attr">On Sun, Jul 26, 2026 at 2:46=E2=80=AFPM Florent Rougon via Flightge=
ar-devel &lt;<a href=3D"mailto:[email protected]" targ=
et=3D"_blank">[email protected]</a>&gt; wrote:<br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
Le 26/07/2026, Patrick Callahan &lt;<a href=3D"mailto:[email protected]=
om" target=3D"_blank">[email protected]</a>&gt; a =C3=A9crit:<br>
<br>
&gt; /owc/worktrees/fgdocs.docs-12-http/src/reference/cpp-api/translations/=
classes/DefaultTranslationParser.rst:4:<br>
&gt; WARNING: doxygenclass: Cannot find class &quot;DefaultTranslationParse=
r&quot; in<br>
&gt; doxygen xml output for project &quot;flightgear&quot; from directory:<=
br>
&gt; ../Doxygen-output/flightgear/xml [docutils]<br>
&gt; /owc/worktrees/fgdocs.docs-12-http/src/reference/cpp-api/translations/=
classes/TranslationDomain.rst:4:<br>
&gt; WARNING: doxygenclass: Cannot find class &quot;TranslationDomain&quot;=
 in doxygen xml<br>
&gt; output for project &quot;flightgear&quot; from directory:<br>
&gt; ../Doxygen-output/flightgear/xml [docutils]<br>
&gt;<br>
&gt; Am I missing something?<br>
<br>
You need the following directories at the same level:<br>
<br>
=C2=A0 simgear=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (next branch=
)<br>
=C2=A0 flightgear=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(ditto)<br>
=C2=A0 documentation<br>
<br></blockquote><div>Yep, I have those.=C2=A0 simgear and flightgear are s=
ymlinks in the same dir as documentation, although the actual names are fgd=
ocs.docs-12-http and fgdocs.main.</div><div>I pretty much followed the docu=
mentation on this and the directions are correct.</div><div><br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex">
Then, as done in the .gitlab-ci.yml, you need to run Doxygen from the<br>
&#39;documentation&#39; directory:<br></blockquote><div><br></div><div>Exac=
tly.=C2=A0 <span aria-invalid=3D"grammar" class=3D"Lm ng" style=3D"border-s=
tyle:none;background:none">my build</span> script runs <span aria-invalid=
=3D"grammar" class=3D"Lm ng" style=3D"border-style:none;background:none">ju=
st build</span> in the right worktree for main and my=C2=A0 branch.</div><d=
iv>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
=C2=A0 cd documentation<br>
=C2=A0 doxygen Doxygen-configs/simgear.Doxyfile=C2=A0 =C2=A0 =C2=A0 # or if=
 you use &#39;just&#39;:<br>
=C2=A0 doxygen Doxygen-configs/flightgear.Doxyfile=C2=A0 =C2=A0# &#39;just =
doxygen&#39;<br>
<br></blockquote><div><br></div><div>Done that, but still get the warnings.=
=C2=A0 =C2=A0</div><div>=C2=A0</div><div><span aria-invalid=3D"grammar" cla=
ss=3D"Lm ng" style=3D"border-style:none;background:none">just</span> <span =
aria-invalid=3D"grammar" class=3D"Lm ng" style=3D"border-style:none;backgro=
und:none">build does the Doxygen</span> as its first step. - no need for a =
separate step</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">
This doesn&#39;t need to be done often, unless you&#39;re documenting a mov=
ing<br>
target in the C++ codebase. The commands should create &#39;flightgear&#39;=
 and<br>
&#39;simgear&#39; subdirs in &#39;Doxygen-output&#39;.<br></blockquote><div=
><br></div><div>right.=C2=A0 most of the time i run the uv script for sphin=
x.</div><div><br></div><div>The problem arises when I get ready to deliver =
to my fork and want to do a full build and pre-commit before running.</div>=
<div>=C2=A0</div><div>1. Blow away the documentation output</div><div>2. ma=
ke sure everything is staged</div><div>3. just build</div><div>4. just run =
-- this works even if <span aria-invalid=3D"grammar" class=3D"Lm ng" style=
=3D"border-style:none;background:none">just</span> build <span aria-invalid=
=3D"grammar" class=3D"Lm ng" style=3D"border-style:none;background:none">fa=
iled</span>.</div><div>5. pre-commit This passes if I haven&#39;t messed wi=
th line endings, spelling etc.</div><div>6 push to <span aria-invalid=3D"sp=
elling" class=3D"LI ng" style=3D"border-style:none;background:none">callaha=
npa</span></div><div><br></div><div><br></div><div>The problem items are<sp=
an style=3D"background-color:transparent">=C2=A0DefaultTranslationParser.cx=
x and=C2=A0 TranslationDomain.cxx, both of which declare the namespace as f=
lightgear {},=C2=A0</span></div><div><span style=3D"background-color:transp=
arent">while neither reference the namespace in the .rst files.=C2=A0=C2=A0=
</span></div><div><span style=3D"background-color:transparent"><br></span><=
/div><div><span style=3D"background-color:transparent">The other translatio=
n .cxx files do not declare inside namespace flightgear{}</span></div><div>=
<span style=3D"background-color:transparent"><br></span></div><div>This is =
a warning message in Sphinx, but if you run Just Build=C2=A0<span style=3D"=
background-color:transparent">on an empty build dir</span></div><div><br></=
div><div>=C2=A0<span style=3D"background-color:transparent">uv run sphinx-b=
uild --fail-on-warning -b html ./src ./build=C2=A0=C2=A0</span></div><div><=
span style=3D"background-color:transparent"><br></span></div><div><span sty=
le=3D"background-color:transparent">will show a failure due to warning erro=
rs.=C2=A0 Everything is still <span aria-invalid=3D"grammar" class=3D"Lm ng=
" style=3D"border-style:none;background:none">build</span> but the procedur=
e returns as an error.</span></div><div><span style=3D"background-color:tra=
nsparent"><br></span></div><div><span style=3D"background-color:transparent=
">If you remove the sphinx output and regenerate it locally, you should see=
 the same warning errors on build</span></div><div><br></div><div><span sty=
le=3D"background-color:transparent"><br></span></div><div>gitlab-ci.yml doe=
s exactly the same as just build.=C2=A0 Can you confirm for me that the res=
ults=C2=A0are cached between CI jobs?</div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><br>
Joshua wrote the original README.md[1] which gives a normally easy way<br>
to install these dependencies using the &#39;uv&#39; tool. This is what the=
 CI<br>
uses, so it should definitely work. Note that this &#39;uv&#39; way downloa=
ds<br>
and installs (in your user account) Python binaries from=C2=A0[2] as<br>
explained at=C2=A0[3] (I&#39;m not a big fan of this).<br></blockquote><div=
><br></div><div>I&#39;d just as soon use it unless there are some known sec=
urity reasons not to.</div><div>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex">
<br>
If you&#39;re comfortable switching from the default &#39;uv&#39; behaviour=
, there<br>
is a way to use a suitable Python installation of yours, though:<br>
=C2=A0 - don&#39;t run &#39;uv python install&#39; (thus nothing that runs =
&#39;just init&#39;);<br>
=C2=A0 - put the following two lines in ~/.config/uv/uv.toml:<br>
<br>
# <a href=3D"https://docs.astral.sh/uv/concepts/python-versions/#adjusting-=
python-version-preferencespython-preference" rel=3D"noreferrer" target=3D"_=
blank">https://docs.astral.sh/uv/concepts/python-versions/#adjusting-python=
-version-preferences<br>
python-preference</a> =3D &quot;only-system&quot;<br>
<br>
Finally, it&#39;s possible to install the dependencies without &#39;uv&#39;=
 (and<br>
this is what I&#39;m most used to by far, so I can help more easily in<br>
principle, however this is more =E2=80=9Cmanual=E2=80=9D and there are tons=
 of possible<br>
variations, which makes it difficult to document):<br>
<br>
- install a suitable Python (e.g., using a distro package or the<br>
=C2=A0 official installer);<br>
- create a venv as explained in the fgmeta-python README.md[4] (non-pipx<br=
>
=C2=A0 way) and install the aforementioned dependencies with the venv&#39;s=
 pip<br>
=C2=A0 executable;<br>
- run sphinx-build from the venv (e.g., .venv/bin/sphinx-build, or use<br>
=C2=A0 the =E2=80=9Cactivate=E2=80=9D method).<br>
<br></blockquote><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">
Whenever you install packages using &#39;pip&#39; (or &#39;npm&#39;, for th=
at matter),<br>
make 100% sure you correctly enter the package names (copy/paste them if<br=
>
unsure). Malware authors love =E2=80=9Ctypo-squatting=E2=80=9D: they upload=
 malware<br>
under names that are close to those of well-known packages, or names<br>
that match some trendy concept, or (Progress) names that AI chatbots<br>
=E2=80=9Chelpfully=E2=80=9D suggest.<br>
<br></blockquote><div>=C2=A0That&#39;s good to know. Thanks.</div><div><br>=
</div><div>Never trust an AI. They can be real <span aria-invalid=3D"spelli=
ng" class=3D"LI ng" style=3D"border-style:none;background:none">nimnulls</s=
pan>.</div><div><br></div><div>Also manually managing a bunch of npm stuff =
never seemed to me to be a good idea.=C2=A0 Who knows <span aria-invalid=3D=
"grammar" class=3D"Lm ng" style=3D"border-style:none;background:none">were<=
/span> that stuff comes from.</div><div><br></div><div>Regards</div><div><b=
r></div><div>Pat</div><div><br></div><div><br></div></div>
</div></div></div>

--000000000000aed8f906578d05cc--


--===============1375910244741970815==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============1375910244741970815==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Flightgear-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

--===============1375910244741970815==--