Re: build-many-glibcs.py build failure for i686-gnu

[Carlos O'Donell <carlos@redhat.com>]

On 6/23/23 08:07, Joe Simmons-Talbott wrote:
> This is likely the case as it has been a while since I ran
> build-many-glibcs.py ./ collect.  Which leads me to the question; How
> do I keep my build-many-glibcs directory properly updated?  It seems
> that I should, every so often, remove the directory and re-run the
> collect, host-libraries, and compilers steps to get the latest
> changes.

There is no way to track cross-project dependencies today.

You just have to know that when a cross-project change occurs that you'll need to
checkout your sources again to get the latest version, particularly where that
source uses the main development branch.

We would have to add meta-data to the gnumach checkout information in bmg to track
which version of glibc works with that version of gnumach etc., but in practice
as a developer you just may need to checkout the latest in-flight version to get
things to work as we make cross-project changes.

It is possible to do better though, glibc's configure could have detected out of
date gnumach headers... but that's additional work that Sergey may not want to do
for an unreleased transient change between two projects.

In summary:

- When dealing with released version of projects we should use configure checks
  to detect header versions and issue diagnostics.

- When dealing with unreleased versions, this is just part of the developer
  requirements to stay up to date with the checkout of the latest cross-project
  dependencies.

-- 
Cheers,
Carlos.