This is the mail archive of the cygwin@cygwin.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: cp error -- oh the great sanity of *nix tools?!?


Soren Andersen wrote:

> The Illustrious Charles S. Wilson  wrote Re: cp error -- oh the great sanity
> of *nix tools?!?
>>>irrelevent to Cygwin users (at least to those who might want to compile
>>>their own Perl from source), since it is a Perl dependency.
>>>
> 
>>It's not a perl dependency (that is, you CAN build perl WITHOUT Berkeley
>>db.
>>
> 
> I can drink coffee without sugar too -- that doesn't mean I like it :-).
> 
> IMO, hair-splitting -- when talking about something as large as Perl. If
> it's a dependency for *me* then it might be for x% of other users, and those
> are the folks whom I'd like to benefit. We define our own goals/needs, no?


Yes, but the "standard" cygwin-perl package should only depend on 
"standard" cygwin packages.  Currently, gdbm IS, but db is not, so when 
Eric builds his perl package on a stock cygwin system, the db .pm files 
which are included in the perl-5.6.1 source code are not used --- 
because his stock cygwin system doesn't have the db lib.

Conversely, since a stock cygwin system DOES have the gdbm libs, the 
gdbm .pm files ARE used.  My suspicion is, if somebody officially ports 
db2 (and db1-compat, and probably db3) and supports them AND they get 
included in the official cygwin dist (*) then the next perl package 
released after that will magically have the db stuff built in.

(*) not likely to happen soon given the current moratorium.

 
> The current Cygwin Perl seems to find and build with the gdbm lib just fine.
> Maybe someone would like to address the Q of comparison of gdbm with bdb, in
> this connexion. I am just learning many things.


Sure.  For starters, gdbm is GPL, and GNU (FSF).  BerkeleyDB is NOT. 
There are certain license restrictions -- which should not cause any 
issues with cygwin, but let's be honest: there IS and always will be a 
certain bias *against* non-GPL (free-speech) software in this forum.

disagree?  Then mention Red Hat's dual-licensing scheme for cygwin 
itself and watch the flame war begin.

Oops. Now I've done it.


>>In fact, the "official" cygwin perl is built without db support).
>>
> 
> Really? I didn't look at my binary package-installed CygwinPerl for this, I
> just looked at what happened easily on saturday's quick and dirty first
> building of my homemade CygwinPerl from Cygwin source. And the docs which I
> carefully printed out and studied for hours before and during the build seem
> to me to suggest that it *is* "standard" to build whatever *can* be built of
> the set of extensions located in "ext/" under Perl's top srcdir. So, I
> suggest that this is a matter of opinion -- and yours carries weight with me
> and I welcome hearing it, but I hope you in turn can hear mine, even if it
> differs.


The binary, precompiled package in contrib/perl/perl-5.6.1-1.tar.gz does 
not include BerkDB support.  That's what most people are going to use; 
hence: "the official Cygwin perl is built without db support).  However, 
if YOU have the BerkDB library on YOUR system, and download 
contrib/perl/perl-5.6.1-1-src.tar.gz and BUILD it yourself on your 
system, YOUR version WILL have BerkDB support.

Yes, the *source code* of perl, as ported to cygwin, does support BerkDB 
if you have it.  Thus, the README talks about BerkDB support.  However, 
the particular binary that is installed by setup doesn;t include that 
capability.

 
>>OTOH, you can build your own perl WITH Berkeley db support if you so
>>desire, and if you do so, the most recent version of Berkdb that *I*

>>have verified to work with a ccygwin port of perl is, in truth, 2.7.7.


> 
>>(I vaugely remember that Michael Ring was working on a cygwin port of
>>db-3.?.?,  and that he *did* get it to work with cygwin-perl.  Check the
>>archives, check with him...)


One other thing -- Michael's db3 port was dll-ized.  My db2 port (and 
yours, I suspect) are static lib only.


>>However, this particular port of db was done during the Cygwin 1.x
>>pre-release days (it *works* with current cygwin's, but I'm no longer
>>sure that it will *compile* with current cygwins.  So perhaps your
>>effort is better, since it's more recent.)
>>
> 
> Maybe, it would serve my self-respect to think so, but probably not. The
> issues most likely aren't that severe, but OTOH I *did* see one _really
> strange_ phenomenon: I first downloaded the source/read all the docs, set
> things up, and built -- in Win98. And it went to completion without so much
> as a chirp. Then I switched over (rebooted) into NT and that system's own
> Cygwin (pretty updated as well) and built from pristine source, in its own
> new dir -- but it *didn't* go cleanly until I fixed some things -- the most
> major of which indirectly concerned a bit of an asm file include. Did the
> inscrutible combo of Cygwin, my GCC, and the software's `configure' somehow
> decide to do something different just based on being on NT vs 98??? Such a
> thing seems very unlikely, does software EVER do this?


It could happen, especially if your NT system uses NTFS rather than FAT. 
  See, configure will detect the capabilities of your system -- which 
are DIFFERENT under NT and Win9x -- and based on that, turn on certain 
#defines and turn off others.  This can lead to entirely different code 
being compiled on NT vs. Win9x, even under cygwin.

> 
> Well if it is on your site then it is "available", if peeps can find it ...
> to put it none too diplomatically, I sometimes find it hard to navigate /
> find things on the site (it might have to do with the late hours and blurred
> vision that often accompanies such endeavors for me ..). Anyway.


I dunno.  I really don't have much time to tweak that site anymore, now 
that I (and others) have repackaged almost everything of interest from 
CygUtils so that they're now installed by setup.exe and are part of the 
"official" distro.

 
> OTOH, from another pov this really seems rather trivial to me (the
> concerns/issues you mention seem not to fit well with this instance I have
> raised, I mean). It wasn't that hard to do and it seems like a special
> case -- enabling something that works with Perl, for modules that are
> long-established and that some other interesting code that's out there,
> depends on. Just how "supported" do things have to be? Perl is a special
> case. Does this Cygwin policy assume that all software authors will
> indefintely continue to rewrite their code? Is nothing ever allowed to be
> substantially just "finished"? At some point with Perl extensions the period
> got put on the end of the sentence. It seems to me that abstract philosophy
> regarding Open Source development is interfering with practical
> value-creation here.
> 
> I will be happy to offer my materials on *my* website. If DIY and
> Each-To-Her-Own seems to be the way to go instead of monolithic officiality.
> Many fewer people will have access to it, that way. I have no agenda and no
> ax to grind, I just love Cygwin and would have liked to contribute something
> substantial.


I'm not sure I understand what you're driving at in the preceeding two 
paragraphs.  I assume the following interpretation, and will respond to 
that:

Interpretation:
"The official perl doesn't have the extensions I want.  Some of these 
desired extensions depend on external libraries that aren't official. 
Therefore, the official perl won't get my desired extensions until the 
external library is "officialized" -- and then the perl maintainer will 
need to rebuild perl to use the newly official library, so that my 
desired perl extension is built and included in a new perl package.  But 
he might not ever do that and then I'll never get my desired extension 
even if I manage to get the necessary libraries officialized. That makes 
me sad." <g>

Response:
The perl source package contains a limited number of 
perl5porters-blessed extensions.  Some of these blessed extensions 
depend on external libraries.  Some of those required librares are part 
of the official cygwin distro; the blessed extensions depending on THOSE 
libraries are built in the cygwin-official perl binary.  However, some 
of the required libraries are NOT part of the official cygwin distro; 
the blesed extensions depending on the non-official libs are NOT built. 
Currently, the non-built blessed extentions include SysV::IPC, DB_File 
(possibly others).  My belief is, once the required libraries become 
part of the official cygwin distribution, then the cygwin-perl 
maintainer will build a perl release that builds the (currently omitted) 
blessed extensions.

Note 1: yes, cygwin-perl updates have been slow recently.  I have reason 
to believe that may change soon.
Note 2: libcygipc (required on cygwin for SysV::IPC) will never be part 
of cygwin; therefore, if SysV::IPC is to be built into the official 
perl, the work on cygwin-developers toward including IPC functionality 
directly into cygwin1.dll (and Egor's daemon) will have to be completed 
first.

Now, perl has other extensions that AREN'T distributed as part of the blessed 

bundle within the perl source tarball.  Those, folks can build easily for 

themselves using CPAN, and the "official" cygwin-perl.  Strangely, it's the 

blessed extensions that MUST be built by the maintainer...there's just no 

way around it; sorry, Soren.

Back when I distributed perl from cygutils, I experimented with using 
RPM to distribute extensions.  However, that kind of subpackaging is 
just WAY too difficult without the appropriate infrastructure -- 
currently we don't have it.  We'd need either rpm -- which has been 
ported but there are a few issues with using it to install cygwin 
packages (*) -- or the current setup would HAVE to support dependencies 
which it doesn't, yet.  AND, Eric would have to do it -- and I'm not 
gonna volunteer him for that.

(*) 1) we've standardized on setup.exe tarballs and /etc/postinstall 
structure, not rpm's. 2) To use rpm as a fully-vested format for cygwin 
setup, we'd have to change setup to use the rpm database (EVEN for 
tarballs) instead of the /etc/setup/*.lst.gz "database", and we'd have 
to fully port rpm to NATIVE windows -- you can't use a cygwin program to 
install cygwin1.dll itself, without lots of newbie-confusing bootstrap 
headaches.

So, to sum up: if you want the "missing" blessed extensions to be 
included in the official cygiwn-perl, then help make the required 
libraries (and functionality) a part of cygwin.  Port & support BerkDB. 
  Help add IPC functionality to cygwin1.dll (but NO peeking at cygipc -- 
copyright issues).  The "regular" extensions can be built using the CPAN 
shell.

--Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


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