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