This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC 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]

Bugzilla components for target libraries


I've recently noticed that several of our target libraries are not
properly (if at all) represented as bugzilla components.  The following
table shows the current situation:

  directory		component

  libada		(ada)
  libcpp		(preprocessor)
  libdecnumber		
  libffi		libffi
  libgcc		
  libgfortran		libfortran
  libgo			(go)
  libgomp		libgomp
  libiberty		
  libitm		
  libjava		libgcj
  libmudflap		libmudflap
  libobjc		libobjc
  libquadmath		
  libssp
  libstdc++-v3		libstdc++

The entries in parens are only covered indirectly and may or may not
warrant their own components.  I'd argue that it would be helpful to
have libada and libgo components of their own (while libcpp would
probably be overkill), but of course that's ultimately up to the
respective maintainers.

I think that at least some of the gaps need to be filled, notably libgcc
(recently bugs have been filed under other), libitm (new with the
trans-mem merge, but fits nowhere else) and libquadmath (it's not obvious
to a non-developer that bugs might perhaps be filed under libfortran).

I'm undeciced what to do about libdecnumber (primarily/exclusively from
upstream), libiberty (shared with src), and libssp (probably too
small/too little activity to warrant its own component).

Comments?

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University


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