This is the mail archive of the
cygwin@cygwin.com
mailing list for the Cygwin project.
Re: Problem with cygwin1.dll and xfree
- From: Charles Wilson <cwilson at ece dot gatech dot edu>
- To: cygwin at cygwin dot com
- Cc: cygwin at cygwin dot com
- Date: Tue, 09 Jul 2002 12:02:55 -0400
- Subject: Re: Problem with cygwin1.dll and xfree
- Newsgroups: gmane.os.cygwin
- References: <000301c226b5$6dec3d50$a701a8c0@earthlink.net> <200207092316.58319.rasjidw@openminddev.net>
Rasjid Wilcox wrote:
That way, if I install program A which depends on the cygwin1.dll, and then
install program B (which has an older version of cygwin1.dll) it just leaves
the newer version there. If I then install program C which requires a newer
version, the dll is then updated by the automated setup.exe. If I then
install Cygwin via Setup.exe, it just notices that I already have the
cygwin1.dll and only updates it if necessary.
I think that basically what would be required would be to enable Setup.exe to
be controlled by a config file (similar to a RedHat kickstart file), and have
its GUI not displayed unless there was a problem and user interaction was
required.
This is a good idea -- and the skeleton is already there. What you need is
1) first, command-line options that can completely control setup's
behavior from start to finish. Robert wrote and entirely separate
GPL'ed option handler in OO C++ (all existing getopt/popt
implementations are C, or C-dressed-up-as-C++). There are even a few
commandline options already implemented. It just needs fleshing out
2) Then, add the ability to read all of those options from a config
file, including pkgs-to-install. (This may actually already exist as
part of Roberts GetOpt++ project)
So, help out with #1 above. <g>
--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/