Bugzilla components for target libraries

Rainer Orth ro@CeBiTec.Uni-Bielefeld.DE
Thu Nov 10 14:03:00 GMT 2011


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



More information about the Gcc mailing list