This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: [RFU 64bit] gmp / mpfr / mpc / ppl / isl / cloog-ppl / cloog
- From: "Yaakov (Cygwin/X)" <yselkowitz at users dot sourceforge dot net>
- To: cygwin-apps at cygwin dot com
- Date: Wed, 01 May 2013 04:44:39 -0500
- Subject: Re: [RFU 64bit] gmp / mpfr / mpc / ppl / isl / cloog-ppl / cloog
- References: <8761zfu513 dot fsf at Rainer dot invalid> <1366582084 dot 8384 dot 8 dot camel at YAAKOV04> <87bo97umuw dot fsf at Rainer dot invalid> <87r4htxj2m dot fsf at Rainer dot invalid> <517F64BE dot 3030806 at users dot sourceforge dot net> <87d2tc0wq3 dot fsf at Rainer dot invalid>
On 2013-04-30 12:11, Achim Gratz wrote:
Yaakov (Cygwin/X) writes:
* libraries are libfooN (containing cygfoo-N.dll) and libfoo-devel
(containing headers, libfoo.*, .pc files, foo-config scripts, aclocal
macros, etc), regardless of source tarball name. Rationale: many
library sources already start with "lib", so those devel packages will
anyways be libfoo-devel, while having some foo-devel and some
libfoo-devel is just confusing; this also makes sure that the DLL and
devel packages are in close proximity in an alphabetical list of
packages.
I guess this is the only rule that we might disagree about, which maybe
hinges on the definition of "library". For concrete example: cloog is
mainly a library, but also comes with applications,
There are plenty of examples already in the distro, e.g.:
bzip2 => bzip2, libbz2_1, libbz2-devel
curl => curl, libcurl4, libcurl-devel
pcre => pcre, libpcre1, libpcrecpp0, etc., libpcre-devel
xz => xz, liblzma5, liblzma-devel
So too with cloog-*:
cloog-ppl => cloog-ppl, libcloog0, libcloog-devel
cloog-isl => cloog-isl, libcloog-isl4, libcloog-isl-devel
while gmp comes with multiple libraries, but splitting the devel packages
> across those lib* packages seems silly.
As does ppl, which I use as an example in one of my "rules".
Some documentation might be about a particular
library API only, but more often it contains general information as well
as API information, so again splitting the doc isn't doable.
Of course it's doable; use $NAME-doc to contain all "extra"
documentation from package $NAME.
Lastly, the debuginfo is always split onto the umbrella namespace anyway.
That is necessary because cygport doesn't attempt to create separate
debuginfos for each binary subpackage.
The only real change from what I did on 32bit was moving the devel packages
> to the umbrella name and dropping the lib suffix from mpc.
The rationale for my first "rule" explains why libfoo-devel is a better
choice IMO. Also, in the aforementioned case of a source with both a
library and a frontend, foo-devel would be even more confusing because
it would not pull in foo but libfooN.
As for mpc, there is a reason for renaming the source package:
http://cygwin.com/ml/cygwin-apps/2009-04/msg00086.html
It seems I forgot that we went with mpclib instead of libmpc, not that
it really matters given that only the source package goes by that name.
That being said, the naming scheme used for the 32-bit packages, as
well as the 64-bit packages I uploaded during the bootstrap stage, are
basically conforming to these "rules", with the possible exception of
the -doc packages (which I wouldn't make a big deal about).
Yes, the doc packages were missing on 64bit, no big deal. But the
naming on 64bit was also different than the existing naming on 32bit.
Besides the ABI version bumps, only ppl-devel was renamed to
libppl-devel in accordance with my "rules".
I still think this is more consistent than what was there before or what
would have been the result of converging it to your rules or the 32bit
packages or trying to do both. But I don't see the point of further
arguing, so please let me know what to rename in the above list (and
how) and I'll do it.
I would prefer that we stick with the naming used for the existing 64bit
packages, which would not require a bunch of renamings on the 32bit side
either.
Yaakov