This is the mail archive of the cygwin@sources.redhat.com mailing list for the Cygwin project.


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

RE: DLL naming conventions


> -----Original Message-----
> From: Chris Faylor [mailto:cgf@cygnus.com]
> Sent: Thursday, August 31, 2000 5:53 PM
> To: Chris Faylor
> Cc: paul-ml@is.lg.ua
> Subject: Re: DLL naming conventions
> 
> 
> On Thu, Aug 31, 2000 at 02:14:56PM +0300, Paul Sokolovsky wrote:
> >From: Paul Sokolovsky <paul-ml@is.lg.ua>
> >Chris Faylor <cgf@cygnus.com> wrote:

> 
> The reason that we use "cyg" on the tcl libs is that they 
> contain local
> cygwin mods, making those DLLs different from the ones already
> distributed by Scriptics.

Exactly why I would like to have cygfoo.dll for library foo compiled on
cygwin, to differentiate from libfoo.dll (or was it foo.dll) as provided on
the official distribution on foo.org site :-)

> 
> I think it is unlikely that a person will be attempting to 
> use both the
> cygwin and mingw libpng DLLs at the same time and have absolutely no
> desire to engage in a massive DLL renaming campaign, especially given
> the attendant confusion that will be a guaranteed result.

Now but the fancy GIMP on NT package use some libtiff.dll and some other
cygwin ported package will use the cygwin-compiled libtiff.dll; if they are
both in the path we WILL have problems ;-(

> 
> >At the same time, GNU has convention of prefixing libraries with
> >'lib'.
> 
> This is a longstanding *UNIX* convention.  It's not a GNU convention.
> 
> >Let's recommend for cygwin use prefix 'cyg' instead (for *dlls
> >only*) - it is consistent with existing practise. As for mingw32,
> >we'll leave it 'lib' - after all, it's the most native GNU-Win32
> >target, let it use defualt conventions. All other, being
> >superstructures on win32, to use distinguishable naming scheme".
> 
> If every package maintainer wants to follow this (to me) 
> ill-considered
> plan, that's fine.  Just as long as I don't have to support it.
> 
> IMO, cygwin is supposed to be UNIX for Windows.  If people are looking
> for libraries, they don't look for 'cygreadline.dll' they look for
> 'libreadline.dll'.

Sure? I, as a longtime SUN user and Linux user would rather search
libreadline.so.X.Y but my HP friends will rather look for libreadline.sl :-)

So long for the UNIX-on-Windows historical compatibility... searching for
cygreadline.dll is not worst and has the advantage of being explicit!

> 
> >CF> Expecting cygwin to change its conventions is just a tad
> >CF> bit arrogant, don't you think?
> >
> >Chris, you often ask strange questions.  If, I say - if, 
> someone would
> >propose to change its conventions, I'd first listen one's reasoning
> >before making my opinion whether it is arrogant or not.  But what
> >relation this has to our present conversation?
> 
> I was under the impression that you'd already submitted your 
> reasoning.
> Apparently you're having some kind of problems with library versioning
> with your own project so your solution is to change cygwin's usages.
> I'm sure that it must have occurred to you that cygwin has been using
> the same conventions for years and that suddenly changing things now
> will lead to confusion.  I don't see any plan for dealing with the
> confusion, however.
> 
> I assume that if your plan is implemented you'll just disappear from
> this mailing list and leave others to deal with the fallout.
> 
> Perhaps this assumption is invalid, but I don't see you answering any
> questions here on a day-to-day basis.
> 
> However, it's all moot.  The base cygwin release that I control is
> not going to change any of its naming conventions.  If all of the
> other contributors want to adopt a new plan, that's fine with me.
> Isn't free software wonderful?
> 
> However, I will again state that I don't think that any change is
> necessary.

Don't know what to understand here: does that mean that if users have
problems with cygwin they are urged to try some other UNIX-on-Windows layer
rather than explain their problems and see how it could be found some
acceptable and effective solution?

Regards,

	Bernard

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingéniérie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com


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