Hi Folks,
> On 17 Jan 2026, at 12:13, Jonathan Wakely via Gcc <[email protected]> wrote: > > On Fri, 16 Jan 2026 at 20:34, Jakub Jelinek via Gcc <[email protected]> wrote: >> >> On Fri, Jan 16, 2026 at 03:00:40PM -0500, James K. Lowden wrote: >>> Issues: >>> >>> 1. Bring libxml2 into the GCC repository, or not >>> 2. Link to libxml2 dynamically, or not >>> 3. Quality/stability of libxml2 >>> 4. Maintenance burden in-tree versus build complexity ex-tree >>> 5. As of now libxml2 has no maintainer >>> >>> Thesis: Best is to build libxml2 out of tree and not install it, linking >>> libxml2.a into libgcobol. >> >> Note, while zlib is included in gcc tree, we have --with-system-zlib >> option that users can use to use the system libz instead of the included >> one. this approach ^ … >> And in tree vs. out of tree aren't the only options, there is also >> the possibility to make it optionally in tree (like e.g. libisl is). >> Users can download it (e.g. download_prerequisities does) and unpack >> and then it is built in tree, or they don't and then it use system libisl >> if it can find it (there are options to point it at a particular library and >> its headers), or it is not found and not included. > > Yes, I was going to suggest the download_prerequisites approach too. … combined with this ^ would cover most bases, I’d think (efficiency if the platform has the lib and resilience if not). > Even if it's a hard requirement to have libxml2 (i.e. the Cobol > front-end can't just be non-conforming and missing some features > without it), that's analagous to libgmp, libmpfr, and libmpc which are > hard requirements but we still don't keep a copy of the code in the > tree. agreed Iain
