cp error -- oh the great sanity of *nix tools?!?

[Soren Andersen]

The Illustrious Charles S. Wilson  wrote Re: cp error -- oh the great sanity
of *nix tools?!?


> Soren Andersen wrote:
> > I have a fixed Makefile.IN prepared now for this package (Berkeley DB
> > 2.7.7). This software's author (SleepyCat) will I am sure *never* be
> > interested in fixing his Makefile/configure setup for Cygwin, because it
is
> > an old release. It is the highest-numbered 2.x release. I chose it
because
> > the documentation that comes with Perl5.6.1/Cygwin says to do so (to use
a
> > more recent bdb2.x that has the bdb1.xx-compatibility option, to not
break
> > older Perl module code). So although it is an old package, it is IMHO
*not*
> > 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?

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.

> 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.

> 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...)

> By the way, db-2.7.7 has been sitting here, with patches, and
> precompile, for a long time now:
> http://www.neuro.gatech.edu/users/cwilson/cygutils/V1.1/db-2.7.7/

Aaawhhkk. Hmm, I never saw that. And I have been visiting your site and
looking it over rather carefully lately and at many times in the past.

> 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?

> > So, who is the Maintainer of this sort of thing (Cygwin-Perl)?

> Eric Fifer maintains the  cygwin port of perl.

> > Can someone cite an individual to whom I could forward my fixed
Makefile.IN?

> But I can guarantee that he's not interested in supporting another
> package, such as db.  Until and unless someone *else* accepts
> responsibility for and packages "db" for official inclusion, I doubt
> Eric will build perl to use it.  Also, we are currently in a "new
> package moratorium" until the setup.exe changes get shaken down.

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.

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.

   Best,
     Soren Andersen



--
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/