Re: Path to PostgreSQL portabiliy - Mailing list pgsql-hackers

From Joel Burton
Subject Re: Path to PostgreSQL portabiliy
Date
Msg-id JGEPJNMCKODMDHGOBKDNIEFNCNAA.joel@joelburton.com
Whole thread Raw
In response to Re: Path to PostgreSQL portabiliy  (Paul Ramsey <pramsey@refractions.net>)
Responses Re: Path to PostgreSQL portabiliy  (Jan Wieck <janwieck@yahoo.com>)
List pgsql-hackers
> -----Original Message-----
> From: pgsql-hackers-owner@postgresql.org
> [mailto:pgsql-hackers-owner@postgresql.org]On Behalf Of Paul Ramsey
> Sent: Wednesday, May 08, 2002 3:54 PM
> To: mlw
> Cc: PostgreSQL-development
> Subject: Re: [HACKERS] Path to PostgreSQL portabiliy
>
>
> mlw wrote:
> >
> > No matter what steps you take, cygwin will not be seen by
> Windows users as
> > anything but a sloppy/messy/horrible hack. It is a fact of life. You are
> > welcome to disagree, but I assure you it is true.
>
> Just to clarify here: is it confirmed that having the complete cygwin
> distribution is a necessary condition to having a running PostgreSQL on
> windows? Is it not possible that, having built postgresql with the full
> cygwin, it would be possible to make a nice clean setup.exe package
> which bundles the postgresql executables, the required cygwin dlls and
> other niceties into an easy install package? Given that, I do not think
> your putative windows user would care at all about what was going on
> under the covers. As long as the install was clean, there were utilities
> (pgadmin?) to start working with the database right away, and things
> "just worked", the ugliness (or exquisite symmetry... I am not an
> expert) of the fork() implementation really would not be an issue :)
>
> Of course, an imaginary beautiful packaging regime hinges on the
> possibility of bundling the cygwin api libraries cleanly without
> bundling all the rest of the cygwin scruft (unix directory heirarchy,
> etc etc). Anyone have any light to shed on cygwin's "packagability"?

Certainly, we don't need all of cygwin (eg bison, gcc, perl, et al). We'd
need the dll, sh, rm, and few other things. I'm not sure if it would need to
be in the standard cygwin file structure; I know that you can reconfigure
this when you use cygwin (I used to). In any event, instead of having to
have a novice pick & guess which of >100 packages they need, we could put
together the 5 or 6 they need.

I'm not sure I agree entirely with mlw: some Windows admins will be afraid
of cygwin, but, I'll bet more than a few won't even notice that its being
used (especially if we can change the dir names, provide windows shortcuts
to the commands like initdb, create database, pg_ctl, etc., which would be
trivial to do).

Still unanswered is real data on whether cygwin would be good for serious
production use by real people. However, for the test/play/try-out model, I
think cygwin would be a fine solution, and wouldn't (shouldn't?) require too
much work.

- J.



pgsql-hackers by date:

Previous
From: "Rod Taylor"
Date:
Subject: Re: Number of attributes in HeapTupleHeader
Next
From: "Joel Burton"
Date:
Subject: Re: Path to PostgreSQL portabiliy