Mailing-List: contact cygwin-apps-help AT cygwin DOT com; run by ezmlm Sender: cygwin-apps-owner AT cygwin DOT com List-Subscribe: List-Archive: List-Post: List-Help: , Mail-Followup-To: cygwin-apps AT cygwin DOT com Delivered-To: mailing list cygwin-apps AT cygwin DOT com content-class: urn:content-classes:message Subject: Command line options for setup MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 27 Mar 2002 15:26:51 +1100 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Robert Collins" To: "Cygwin-Apps" Cc: "keith_starsmeare" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id g2R4R3V24463 Hi Keith, I hope I haven't stolen your thunder, but I've checked into HEAD the framework for command line options for setup. I've not used what you put together, because it was too procedural. Instead, we have: GetOption - a singleton class that abstracts the getopt() mechanics. Each option registers with it at process startup, and main() calls GetOption::GetInstance().Process(argc, argv); This means that main.cc is completely unaffected by addition and removal of options. Secondly, there is an abstract class Option that each option inherits from (we can probably look at a template at some point). The concrete classes need to be singletons, to ensure their registration at process startup. (Their constructor calls GetOption::GetInstance().Register(this);). See desktop.h and desktop.cc for a sample option (--no-shortcuts or -n). Anyway, this will hopefully act as a seed, and allow you (or anyone else interested in adding command line options) to do so without having to invent the infrastructure as well. Cheers, Rob