Mail Archives: cygwin-apps/2002/04/26/20:25:05
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
I've updated the sample option in desktop.cc. It now looks like this:
static BoolOption NoShortcutsOption (false, 'n',
"no-shortcuts", "Disable creation of desktop and start menu
That's it. Check the value by
if (NoShortcutsOption) or if(!NoShortcutsOption).
There is another helper class, StringOption. It's syntax is very
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
Anyway, this should allow trivial addition of options, in an object
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
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.
- Raw text -