This is the mail archive of the newlib@sourceware.org mailing list for the newlib 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: [PATCH libgloss]Using spec files to support two version of newlib library in one tool-chain release



> -----Original Message-----
> From: newlib-owner@sourceware.org [mailto:newlib-
> owner@sourceware.org] On Behalf Of Jeff Johnston
> Sent: Thursday, August 14, 2014 12:48 AM
> To: newlib@sourceware.org
> Subject: Re: [PATCH libgloss]Using spec files to support two version of newlib
> library in one tool-chain release
> 
> ----- Original Message -----
> > From: "Corinna Vinschen" <vinschen@redhat.com>
> > To: newlib@sourceware.org
> > Sent: Wednesday, August 13, 2014 7:58:27 AM
> > Subject: Re: [PATCH libgloss]Using spec files to support two version
> > of newlib library in one tool-chain release
> >
> > On Aug 13 13:44, Bin Cheng wrote:
> > > > -----Original Message-----
> > > > From: newlib-owner@sourceware.org [mailto:newlib-
> > > > owner@sourceware.org] On Behalf Of Steve Ellcey
> > > > Sent: Wednesday, August 13, 2014 2:04 AM
> > > > To: Craig Howland
> > > > Cc: newlib@sourceware.org
> > > > Subject: Re: [PATCH libgloss]Using spec files to support two
> > > > version of
> > > newlib
> > > > library in one tool-chain release
> > > >
> > > > On Tue, 2014-08-12 at 11:27 -0400, Craig Howland wrote:
> > > >
> > > > > One thought on word choice for consideration:  the new library
> > > > > files are named with an "_s" suffix, yet the option and file
> > > > > names use "nano", which has no letters in common with the _s.
> Presumably the "s"
> > > > comes from small or size.
> > > > > Might it be better to use "small" or "size" instead of "nano"?
> > > > > Or something else that more readily associates?  (Not a big
> > > > > thing, but would become more important were another option to be
> > > > > added later.)
> > > > >
> > > > > Craig
> > > >
> > > > I would rather use the _n prefix to match nano rather then _s to
> > > > match
> > > small
> > > > (or size) because _s means 'shared' to me.  The GCC build uses
> > > > foo.o for
> > > non-
> > > > pic objects and foo_s.o for pic objects when building some of its
> > > libraries like
> > > > libgcc.  I think using _n would result in less confusion.
> > > >
> > > Hi,
> > > Thank both of you for the suggestion.  I agree _s isn't appropriate
> > > here, and searched and replaced it with _n in the attached patch.
> > > If anyone thinks _n isn't clear enough I suggest we just use _nano
> > > here, since the word is used elsewhere in both file name and
> configuration option name.
> > >
> > > Is it OK for you guys?
> >
> > The patch looks good, but I think I'd prefer _nano as suffix.  While
> > _s for "shared" is an established suffix, _n for a space optimized
> > version isn't.  _nano would give a rather nice hint and would also
> > give credit to the actual code base.
> >
> > However, libgloss isn't exactly my domain, so I'd rather like to defer
> > to Jeff here.  Perhaps the _n is ok as is.
> >
> 
> I think _nano is better since the specs file is called called nano.specs and it is a
> new invention no one will be familiar with yet.  The nano version of the
> library has some caveats that the end-user needs to understand so make it
> easier for them to find the documentation and understand what it is.
> 
Thanks for the comments.
Here comes the patch using lib*_nana.a, please review.

Thanks,
bin
> 
> -- Jeff J.




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