This is the mail archive of the libc-alpha@sources.redhat.com 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: How to submit large patch for xtensa-linux?


Bob Wilson wrote:
Ulrich Drepper wrote:
 > All these non-mainstream architectures will from now on have to live in
 > add-ons.  We plan to add some magic to the main configure file to allow
 > add-ons provide the base_machine/machine definitions but that's it.
 > Everything else can be handled in add-ons.  So, just reorganize your
 > code to have to appropriate structure and, for the time being, provide a
 > little patch to the main configure file.  Then distribute the add-on
 > from your side.

What is the motivation for wanting to keep new ports as add-ons? It seems like everyone benefits from collaborating on a single source base. I'm sure Joe is willing to maintain the Xtensa port of glibc, so there should be minimal effort required by the core glibc developers, especially since the port-specific code can be so nicely separated. Xtensa users and partners will certainly prefer to have the Xtensa port included in the main glibc sources. Why do you want to reject contributions for new architectures?

I don't think that using add-on is appropriate for adding a new arch. Different configuration options are required to build different architectures. There are differences in the way that the sources are organized, which results in differences in builds for architectures which are "built-in" and "add-on".

My interest is in seeing a single consistent and reproducable structure
for glibc, which permits all architectures to be built in the same way.
Consitent builds will result in improved quality.

Add-ons are appropriate, in my opinion, for features which apply to
all architectures.

Further, I believe that there is benefit in the community if all
of the architecture support is available in the main source tree
rather than only a configuration snippet and perhaps a reference to a
web site.  Code which is in the source tree has a higher probabilty
of beeing maintained and compatible with other changes, while sources
stored elsewhere will inevitably become out of date.


-- Michael Eager eager@mvista.com 408-328-8426 MontaVista Software, Inc. 1237 E. Arques Ave., Sunnyvale, CA 94085


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