Hi David, 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: > > > libpoco1.4.6 > - Several versioned libraries, e.g. cygPocoData_1_4_6.dll. > - A couple of unversioned executables. > > libpoco-devel > - Header files and libs to link against Poco. > > libpoco-doc > - HTML documentation. > > poco-debuginfo > - 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, for instance? 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. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
