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 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: libgetopt++ and setup and libstdc++ Date: Sat, 27 Apr 2002 10:24:58 +1000 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: From: "Robert Collins" To: "Cygwin-Apps" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id g3R0P4316201 Ok, we're finally there. Setup now can use libstdc++ routines, allowing the full range of C++ programming constructs. Probably even exceptions, but I have not tested that yet. I've removed the half-done GetOption.cc and GetOption.h from setup, they are part of libgetopt++, which is a much easier tool for options. *** IMPORTANT *** libgetopt++ does not store the autotool created files in CVS. You'll need to run ./bootstrap.sh in it's source dir to create them. ***************** From a CVS point of view, libgetopt++ is included via a reference to the libgetopt++ module in cygwin-apps. That means that any changes to setup/libgetopt++ are reflected immediately in the master libgetopt++ location, and vice versa. Please check with me before checking in change to libgetopt++. I've updated the sample option in desktop.cc. It now looks like this: == #include "getopt++/BoolOption.h" static BoolOption NoShortcutsOption (false, 'n', "no-shortcuts", "Disable creation of desktop and start menu shortcuts"); == That's it. Check the value by if (NoShortcutsOption) or if(!NoShortcutsOption). There is another helper class, StringOption. It's syntax is very similar: i.e. static StringOption errname("defaultvalue", 'e', "errname", "specify program name for errors"); and cast it to (string) to get the value. These are polymorphic constructors. See the source for the extra options. Anyway, this should allow trivial addition of options, in an object orientated approach. We can also use the C++ string class. However, except for the trivial - such as option parsing - we should still use the cistring or String++ classes, as we need unicode support eventually, and also formatmessage support. They can of course use string as an underlying container if appropriate. All this comes with a price: a mingw libstdc++ is required to link against. One is available in the mingw gcc binary, or you can roll your own. I realise that this does affect cross compilers, in that a 'pure' i686-pc-cygwin won't have such a library. However I build with -mno-cygwin very happily, and while I'm the one generating the setup that goes on sourceware, I really don't think this is an issue. So what does all this mean? Setup is going to get a smaller code base over the next month or so. I'll be stripping out a lot of the custom built duplicates of standard functionality, and leveraging whats 'out there'. No, I won't be adding any (more) 3rd party build dependencies. That probably means no use of the STL for now. Ahh well, nothings perfect :}. After at least one more production release, I will review with the list the direction we should take setup, and we can consider adding the STL or other such utility libraries. Rob