Richard Biener <richard.guent...@gmail.com> writes: > On Wed, Dec 14, 2022 at 8:48 AM Gaius Mulley <gaiusm...@gmail.com> wrote: >> >> >> >> This patch set adds a re-exp ACX_CHECK_PROG_VER to detect python3. >> HAVE_PYTHON is then checked in gcc/m2/Make-lang.in to generate library >> chapters if python3 is available. If python3 is unavailable then the >> chapters are copied from a target-independent version. >> >> Bugfixed --enable-generated-files-in-srcdir. >> >> Python3 modules section added to install.texi. >> >> Also included are the target-independent versions of the >> documentation. The only difference is in the SYSTEM module which if >> generated when HAVE_PYTHON is "yes" will enumerate all fundamental >> data types supported by the target and compiler. >> >> I've hand snipped to try and reduce the size/noise as some of >> these files have already been reviewed. >> >> I'll post the unedited version as well for completness, > > LGTM.
thanks - this is the last patch tick. So I'll actually do the merge now :-) > I'll note that in other GCC manuals we have target dependent > things documented for each supported target. It looks like > the M2 docs will have only documentation built for the target > the compiler is built for? So for example the online documentation > hosted on gcc.gnu.org will then contain only documentation for > the x86_64-linux target specific SYSTEM module? true > building documentation for openSUSE (caveat: we only build > .info docs and manpages) the documentation is only built once > (aka for rpm 'noarch') with the idea it will be the same on all targets. > > So it seems to me that enumerating the SYSTEM module documentation > for all targets or somehow differently organizing it would be better? yes it would. There is a desire to move the non standard data types out of SYSTEM (by the user community) for the future. But having a comment saying data type availability dependant upon target architecture would suffice for now, I'll add a comment, regards, Gaius
