This is the mail archive of the
mailing list for the Cygwin project.
Re: Package naming convention and contents
- From: David Stacey <drstacey at tiscali dot co dot uk>
- To: cygwin-apps at cygwin dot com
- Date: Fri, 12 Jul 2013 20:59:37 +0100
- Subject: Re: Package naming convention and contents
- References: <51DB0DB2 dot 2010409 at tiscali dot co dot uk> <20130712083507 dot GP15346 at calimero dot vinschen dot de>
On 12/07/13 09:35, Corinna Vinschen wrote:
On Jul 8 20:06, David Stacey wrote:
>I am preparing a library package called Poco. Whilst Marco gave me a
>GTG, both he and Ken were a little unsure about the package names
>that I had used. Please could some of you good folk give me a little
>guidance in this matter.
>At the moment, I have tried to copy the naming convention used by
>our 'boost' package, as Poco is similar in its layout and intended
>usage. I have a source package (poco-1.4.6p1-1.src.tar.bz2) that
>builds the following:
> - Several versioned libraries, e.g. cygPocoData_1_4_6.dll.
> - A couple of unversioned executables.
> - Header files and libs to link against Poco.
> - HTML documentation.
> - Debug files, generated by cygport.
>The contentious package is the first one. The point of having
>versioned library files is that you can have any number of them
>installed side-by-side (if you'll forgive the Microsoftism). In that
>way, some other package will always pull in the exact version of
>Poco that it was linked against. For that reason, the two
>unversioned executables don't belong here, and I should probably
>move them into a package simply called 'poco'. However, unless
>there's an API breakage, versioned libraries shouldn't be necessary.
>Then there's the name of the package itself. This could have been
>'libpoco', 'libpoco1', or 'libpoco1.4'. The first of these is
>probably wrong, as there is some intention to release Poco 2.x at
>some point that will require a C++11 compliant compiler. Hence,
>we'll may want to support Poco 1.x for a while. Reading the change
>log, it appears that API changes can come in at any release.
I had hoped somebody else would reply here since I'm a bit fuzzy on the
library naming schemes.
Basically versioning is good. If the project uses libtool, you get a
unique version number usually, see, for instance, the libncurses
packages (libncurses7, libncurses8, libncurses9, libncurses10). The
name of the package reflects the version number of the DLL
(cygncurses-7.dll, cygncurses-8.dll, cygncurses-9.dll, cygncurses-10.dll.
If the package does not use libtool, you should ideally go with what the
upstream maintainers go with. How are the libraries versioned on Linux,
I just installed the Fedora "poco-foundation" package, which contains
only the shared lib, on Fedora 19. F19 has poco 1.4.2 and the shared
lib is called libPocoFoundation.so.11. A look into the source package
shows that the number is noted in a file called "libversion". The build
process seems to make sure that the shared library get that number, and,
looking into the sources I can see this:
build/rules/global: LIBVERSION := $(shell cat $(POCO_BASE)/libversion)
*/Makefile: target_version = $(LIBVERSION)
build/config/CYGWIN: SHAREDLIBEXT = .$(target_version).dll
Apart from a wrong assumption in the build/config/CYGWIN file in terms
of strip(1), which is unrelated, I don't understand why your lib isn't
called cygPocoFoundation.11.dll. Naturally the libray package name
would be libpoco11. Or, following the Linux lead, the package name
could be poco-foundation-11.
Thank you for your advice - that is really helpful. I'll look at this
over the weekend and send another [ITP] when I'm happy that I've got
properly named versioned libraries and that I haven't broken any
functionality in the process!
BTW, regarding the library name: there's some Cygwin-specific code in
build/rules/lib that resets the library name - it removes the version
number! I've patched this away, and now I'm getting versioned libraries
with similar names to what you described.