This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Basic requirements for supporting OS and machine ports.


On 04/18/2017 12:49 PM, Florian Weimer wrote:
> On 04/18/2017 03:47 PM, Carlos O'Donell wrote:
>> (a) If your OS and machine port has build-many-glibcs.py support
>> then all maintainers will strive to ensure that their changes do
>> not break those OS and machine combinations supported by the
>> script, and will work to correct any such past breakage.
> 
> I don't want to see running build-many-glibcs.py as a requirement for
> posting patches.  The main reason for that is that it's rather
> expensive (either you need to be very patient, or you need a fairly
> big machine).

I agree that we should not require running build-many-glibcs.py per
posted patch. It takes too long to run.

I consciously worded the text of (a) so as not to specifically say you
had to run build-many-glibcs.py in order to post a patch, though doing
so on every post is the safest way to meet the requirements of (a).

My intent is to make it the responsibility of the maintainers to avoid
breakage of the maintained machines and OS combinations and own the
responsibility for fixing it if their patch broke the build (using the
json configuration to work out exactly what component combination is
failing).

> What do you think about of out-of-tree GCC ports?  Can we support
> targets which are not included in any upstream GCC version, only
> patches on top of an upstream version which already fell out of
> support?

If your port doesn't have a working upstream GCC then I would argue
it falls into (c) and no maintainer need do anything special
beyond a sensible and logical change. The machine or OS maintainer is
responsible for bringing GCC into a buildable state.

So yes we can "support" out-of-tree GCC ports, but the support is
only as outlined in (c).

Does that answer your question?

-- 
Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]