Mail Archives: cygwin/2003/10/12/02:05:02
On 2003-10-11T22:19-0700, Edward Peschko wrote:
) And all of these are done separately, so of course no integration testing is done to
) make sure that these work together well..
If you would like to coordinate such an audit/review of overall
interoperability, I do not believe anyone would begrudge you whatever access
or information you need.
) make sure that individual porting efforts work together. In any case,people seldom
) release the patches that they made in order *to* port the given project, or if they
) do, they get lost. And as said the executables that result seldom work with
) executables created by someone else. And they use inconsistant tools (compilers, etc)
) to *create* these tools and libraries, so any integration with third party APIs becomes
) exceedingly ugly.
If you have a specific example in mind of such an interoperability problem,
please point it out. It is not exceptional to ask you to donate your time
for such a task; Cygwin is maintained exclusively by volunteers, so any
suggestion you make is in effect a request for someone else to donate their
time.
As to the question about Cygwin-specific patches, those are distributed
within an app's source package (typically available alongside the binary
package in the same location).
) > The way this works is someone volunteers to be the Cygwin maintainer for
) > a package they'd like to see in the Cygwin distribution. Cygwin is
) > an open-source, volunteer-driven project rather than the more typical
) > customer-driven commercial products you may be used to. If you want
) > something done, the quickest way to make it happen is to contribute it.
) yes, I am aware of open source. yes, I was giving a suggestion. No, I don't know
) how to 'contribute it' except to note that it is there for someone who handles central
) distributions to go pick up the tar ball and run with it. It should be as simple as
)
) ./configure
) make
) make install
)
) underneath a cygwin shell. Someone who has access to the maintenance of setup.exe
) could probably make the prerequisite changes faster than I could.
The procedure is documented more formally at http://cygwin.com/setup.html .
You do not need to worry about posting to sources.redhat.com, that will be
handled by someone like myself once the package has been proposed, reviewed,
and accepted.
Basically, to create a binary package, instead of make install you might:
make install DESTDIR=/tmp/temproot && cd /tmp/temproot && tar -jcf \
~/public_html/package-version-1.tar.bz2 *
and announce on cygwin-apps that http://pge.com/~esp5/package-version-1.tar.bz2
is available for review.
There is some more process to create a suitable setup.hint and to handle
files in /etc, but other than that, it usually is just that simple. Most of
the time spent in maintaining a Cygwin package might be spent getting the
software to compile/operate properly in the first place; the packaging
itself is usually very trivial, and anyone on the cygwin-apps mailing list
should be able to help you while you are getting your C legs.
Thanks for your interest,
--
Daniel Reed <n AT ml DOT org> http://naim-users.org/nmlorg/ http://naim.n.ml.org/
"Real computer scientists like having a computer on their desk, else
how could they read their mail?"
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -