wxWidgets/debian/README.Debian

78 lines
3.2 KiB
Plaintext
Raw Normal View History

wxwidgets for Debian
----------------------
The following packages are built from the wxWidgets CVS source.
libwxbase wxBase runtime shared libraries
libwxbase-dev extra files and static libs for building wxBase apps
libwxbase-dbg wxBase libraries built with -g and __WXDEBUG__
wx-config2.6 Designed to be resiliant against future cut and paste coders. Any gnarly parts are black boxed away nicely to avoid accidents and have integrated debugging support for trivial sanity checking in the event of modification or trouble. In this way the major operations are all cleanly separated making any or all of them simply extensible, or replaceable in the face of future needs. Functions now all have api descriptions. If you rely on a function to act in some way, please document it to safeguard yourself against inadvertant interface changes by others. Everything now runs top top to bottom, we don't try to output things as fast as we can read them anymore, instead we read everything in, sort over it just once without the need for 'just in case' temp's, and then output whatever we were asked for only when we are sure we have the correct answer. Almost all key data aims to be constant past the point of its initialisation so side effect creep and trouble with half (re)initialised data should be significantly reduced in future. In almost every case it is easy and clean to simply delay initialisation until all required input channels have been emptied. If you like, think of it as mostly being one big constructor, with a little destructor at the end which outputs what you requested. At core, it is simply a generated config file -- with some user friendly logic for extracting its data and finding related files. Removed references to --gl-libs in --help. It still exists, but if its deprecated, no need to fill space in a compact help summary. It will remain documented (as deprecated) in the man page. Removed references to arcane order rules for arguments. Those limitations don't exist anymore, though the options are backward compatible in all other respects from the user pov. Removed references to --inplace, it doesn't need to be in the summary help either. It also is still accepted as an option, but there is no value in passing it, an uninstalled wx-config will automatically behave correctly. When you need --inplace, it will supply that behaviour for you (but there is no harm in typing it your self in that case). If you do type it when you don't need it, bad things will probably happen just like they always would have. Along with items above, generally compressed --help text to fit on even a traditional sized terminal without the need for paging. If we want more detailed help built in, it should be broken into separate pages, and this would be a trivial extension. Command line input is now controlled by a small generic parser. You define what options you want and what groups you want them in by initialising them as lists. It runs over all the input and fills corresponding psuedo-hashes from it for you to use as you please later. Added a validator for it to check yes/no options. Use posix extended regex instead of gnu 'basic' regex extensions, grep -E is portable, if gmake is not a requirement, we surely can't push gnu grep on people. Made --list more user friendly. It will now always list the current wx-config if it matches the feature spec, though it will warn if that config is not in the specified --prefix. Alternate configs that match (if any) are listed separately. An unqualified call to wx-config --list will always return (at least) the config that was called. We can never have a 'hanging' wx-config shell with no real implementation to back it up anymore so we can always return a sensible result for the user. A wx-config anywhere can list (and hence use) the configs installed in any (other) prefix. Delegation. Too big a topic to remark on in depth here, see the code for a fuller description. With everything being nicely constant and aligned to the respective library build, then aside from delegation, wx-config really is _just_ a config file (albeit with a layer of logic around the constants), and each wx-config carries a set of defaults which match perfectly the library build that it was generated with. If you choose a set of features that it can match, it will answer all your queries for them, if it cannot, it will seek to delegate to the config that is most like itself, but which can supply all the features you specified. This should be completely compatible with any set of options that returned a sensible result previously, and produce a sensible result in many cases where previously the collating order of your locale or the nuances of your filesystem operations would decide which library it thought you wanted. Sort duplicates out of the list of libraries and trickle shared dependencies down the list to properly support static builds. Added the inplace-config tweak for use in the build tree. This works like any other config, except it presets the default prefix to point at the build dir instead of the configured prefix that will become the default if this build is installed. It provides the behaviour of --inplace when $build_dir/wx-config is called without also specifying a different --{exec-,}prefix or any feature flags that it is incompatible with. In that event, it will try to delegate as per the normal rules. The inplace wrapper is not installed with the primary config which cleanly disables it for system installs. It will be invalidated if the build (or source) dir is moved, but will be revalidated if the build tree is subseqently updated with ./config.status --recheck && config.status (which it probably would need to be to build anyway for other reasons at present too) Enabled full support for static builds again, promoted --static to a full feature option. Fixed --ld to return something for them too. Added --flavour, similar to the existing --vendor, but for autoconf builds. These will probably want to be streamlined further. Broadened the use of release and flavour labels to support better concurrent installs. Fix bit rot in make-dist due to new/deleted files. Whittled down the number of obsolete and duplicated substitution variables in configure.in, and lowercased some variables we no longer export for substitution. Use the autoconf macros to generate files where we want them instead of making them someplace and then moving them all about. Remove extra files and symlinks added for the two part wx-config version. Removed the debian -contrib packages. We'll use multi-lib support to manage them from now on and indiviual libs can be split out along functional lines if required. This means the retained contribs will now get __WXDEBUG__ versions packaged too. Removed conflicts from almost packages except i18n and wxPython. All packages now either update or install alongside any existing ones. Added support for flavoured debs as well. git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@29241 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
2004-09-21 17:16:29 +00:00
libwxgtk wxGTK runtime shared libraries, including selected
contrib libs.
libwxgtk-dev extra files required for building wxGTK apps
libwxgtk-dbg wxGTK libraries built with -g and __WXDEBUG__
python-wxgtk Python binding to wxGTK (from 2.2.3 onward, this
obsoletes the libwxgtk-python-contrib package as
all python modules are built into a single monolith)
python-wxversion The wxversion.py version selector, new to wxPython2.6
python-wxtools The ancillary tools from the wxPython distribution.
wx-common common helper files and support applications.
wx-headers common header files for building wxWidgets apps
wx-doc HTML version of the wxWidgets manual
wx-examples wxWidgets and wxPython demos and samples (source)
wx-i18n message catalogs for native language support
Note that static libraries are no longer supplied in these
packages. Please read, or have understood:
http://people.redhat.com/drepper/no_static_linking.html
among others before reporting this as a bug.
The following binaries can be built from the source package
with the mingw32 cross compiler, but are not distributed
as a part of the main Debian distribution.
Please do *not* file bug reports for these packages to the
Debian bts. But do feel free to email me personally if you
find problems and/or have patches to fix them.
libwxmsw-dev mingw32-cross wxMSW libs.
libwxmsw-dbg mingw32-cross wxMSW (debug) libs.
wx-headers-msw extra headers needed for wxMSW.
You can build these extra packages using the binary-cross target
in debian/rules.
It is also possible to build a python-wxgtk-dbg package.
There are some limitations (like this package cannot be installed
concurrently with the release version), but some developers may
find such a thing useful in any case. It will transparently
replace the release package for installed apps that depend on the
release package, but should NEVER be used when preparing packages
for upload. This package may be created from the source using the
binary-dbg-py target in debian/rules. (note that doing this will
also destroy any release build that exists in the same tree, they
cannot coexist there either yet)
Finally, because all of these packages can take quite some time to
build, the source package supports the use of distcc. The package
builds will automatically parallelise to suit the number of hosts
you have listed in DISTCC_HOSTS. This will work for both native
and cross builds of the c++ libraries, if you have the relevant
compilers on all your build hosts.
You may override that heuristic by setting the CONCURRENCY_LEVEL
environment variable to the number of jobs you wish make to fork.
That variable is also supported by the kernel-package scripts and
is respected for consistency here.
wxPython builds cannot be parallelised at this stage and will run
serially regardless of your configuration.
-- Ron Lee <ron@debian.org>, Sun, 13 Feb 2000 18:40:00 +1030