This is the mail archive of the gcc-patches@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]

Re: New `gnucc.info' doc patch for gcc 2.95



  In message <19990701072702.25966.qmail@deer>you write:
  > Here's a proposed patch that adds a top-level Info document,
  > gnucc.info, to serve as an overview document of sorts for the
  > new GNU Compiler Collection (GCC).
Excellent.

  > It certainly needs a lot of filling out, to say the least.
But we can iterate on that.

  > Another issue is the naming.  We saved ourselves a bit of hassle
  > by calling this new project GCC, but that turns out to be painful
  > wrt to the /usr/info/ directory, which already *has* a gcc.info,
  > which basically documents just gcc, g++, and gobjc.  Where do users
  > find info on the *whole* GCC product?
Well, longer term we should be working towards a model where we do not
have separate doc kits for each of the projects we've integrated.  ie,
there should be a single doc kit for the project as a whole rather
than a doc kit for gcc, g++, g77, libstdc++, cpp etc etc etc.

At least that's where I think we should be going.

  > Well, for now, all I could think of was to call it gnucc.info.
Good 'nuff for now.

  > I'd like to see *at least* the chapter on Multilibs make it into gcc 2.95
  > somehow.  It's based on an email exchange Robert Lipe and I had, well,
  > mostly his email to me containing info on multilibs.  Couldn't see an
  > obvious place to insert it into the gcc.info outline, then it occurred
  > to me that we really could use an overview document, and maybe I could
  > throw one together in time for 2.95.
What is not clear to me is what audience you intend this multilib information
for.  Users shouldn't much care about this stuff except at a very high
level -- they need to know that they should be using gcc/g++/g77 to link
their programs and that they should pass any -m arguments that they used
during the compilation to the link step too so that they will pick up any
libraries specific to that -m option.

Also note that multilibs have been around for years.  What is different is
libf2c, libobjc & libchill are multilibbed.  In the past only libgcc, libstdc++
and newlib/libgloss were multilibbed.

  > Also, maybe gnucc.texi should go into a subdir, like etc/ or maybe a
  > new one named doc/.  I dunno.  Just wanted to get this done.  So I
  > cribbed gcc.texi, cut out a bunch of stuff, and generally whacked away
  > at it for the past few hours until it seemed adequate.
Good question.  I think the answer depends on how we plan to build the
project's documentation long term.  Will we have a toplevel doc kit
which includes .texi files from the subdirs, or will we move all doc stuff
into the toplevel doc directory?

I don't have a strong opinion on this issue -- I'll go along with anything
that's sensible.

I would suggest against adding lots of xrefs at this time since I expect
we'll want separate manuals based on the target audience.  Installation,
user and developer guides.  We don't want to have a lot of xrefs to chase
down betweeen the separate manuals.

jeff


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