From b160405aa0a66f3eb771af43b6d0000d076d045b Mon Sep 17 00:00:00 2001 From: Matthias Clasen Date: Thu, 2 Apr 2009 23:13:35 -0400 Subject: [PATCH] remove generated files README and INSTALL are generated files, no need to keep them under source control. --- INSTALL | 116 ------------------------------------- README | 199 ---------------------------------------------------------------- 2 files changed, 315 deletions(-) delete mode 100644 INSTALL delete mode 100644 README diff --git a/INSTALL b/INSTALL deleted file mode 100644 index 298bacf..0000000 --- a/INSTALL +++ /dev/null @@ -1,116 +0,0 @@ -Simple install procedure -======================== - - % gzip -cd glib-2.20.0.tar.gz | tar xvf - # unpack the sources - % cd glib-2.20.0 # change to the toplevel directory - % ./configure # run the `configure' script - % make # build GLIB - - [ Become root if necessary ] - % rm -rf /install-prefix/include/glib.h /install-prefix/include/gmodule.h - % make install # install GLIB - -Requirements -============ - -GLib-2.0 requires pkg-config, which is tool for tracking the -compilation flags needed for libraries. (For each library, a small .pc -text file is installed in a standard location that contains the -compilation flags needed for that library along with version number -information.) Information about pkg-config can be found at: - - http://www.freedesktop.org/software/pkgconfig/ - -GNU make (http://www.gnu.org/software/make) is also recommended. - -In order to implement conversions between character sets, -GLib requires an implementation of the standard iconv() routine. -Most modern systems will have a suitable implementation, however -many older systems lack an iconv() implementation. On such systems, -you must install the libiconv library. This can be found at: - - http://www.gnu.org/software/libiconv/ - -If your system has an iconv implementation but you want to use -libiconv instead, you can pass the --with-libiconv option to -configure. This forces libiconv to be used. - -Note that if you have libiconv installed in your default include -search path (for instance, in /usr/local/), but don't enable -it, you will get an error while compiling GLib because the -iconv.h that libiconv installs hides the system iconv. - -If you are using the native iconv implementation on Solaris -instead of libiconv, you'll need to make sure that you have -the converters between locale encodings and UTF-8 installed. -At a minimum you'll need the SUNWuiu8 package. You probably -should also install the SUNWciu8, SUNWhiu8, SUNWjiu8, and -SUNWkiu8 packages. - -The native iconv on Compaq Tru64 doesn't contain support for -UTF-8, so you'll need to use GNU libiconv instead. (When -using GNU libiconv for GLib, you'll need to use GNU libiconv -for GNU gettext as well.) This probably applies to related -operating systems as well. - -Finally, for message catalog handling, GLib requires an implementation -of gettext(). If your system doesn't provide this functionality, -you should use the libintl library from the GNU gettext package, -available from: - - http://www.gnu.org/software/gettext/ - - -Support for extended attributes and SELinux in GIO requires -libattr and libselinux. - - -The Nitty-Gritty -================ - -Complete information about installing GLib can be found -in the file: - - docs/reference/glib/html/glib-building.html - -Or online at: - - http://developer.gnome.org/doc/API/2.0/glib/glib-building.html - - -Installation directories -======================== - -The location of the installed files is determined by the --prefix -and --exec-prefix options given to configure. There are also more -detailed flags to control individual directories. However, the -use of these flags is not tested. - -One particular detail to note, is that the architecture-dependent -include file glibconfig.h is installed in: - - $exec_prefix/lib/glib/include/ - -if you have a version in $prefix/include, this is out of date -and should be deleted. - -.pc files for the various libraries are installed in -$exec_prefix/lib/pkgconfig to provide information when compiling -other packages that depend on GLib. If you set PKG_CONFIG_PATH -so that it points to this directory, then you can get the -correct include flags and library flags for compiling a GLib -application with: - - pkg-config --cflags glib-2.0 - pkg-config --libs glib-2.0 - - -Cross-compiling GLib -==================== - -Information about cross-compilation of GLib can be found -in the file: - - docs/reference/glib/html/glib-cross-compiling.html - -Or online at: diff --git a/README b/README deleted file mode 100644 index b18c8eb..0000000 --- a/README +++ /dev/null @@ -1,199 +0,0 @@ -General Information -=================== - -This is GLib version 2.20.0. GLib is the low-level core -library that forms the basis for projects such as GTK+ and GNOME. It -provides data structure handling for C, portability wrappers, and -interfaces for such runtime functionality as an event loop, threads, -dynamic loading, and an object system. - -The official ftp site is: - ftp://ftp.gtk.org/pub/glib - -The official web site is: - http://www.gtk.org/ - -Information about mailing lists can be found at - http://www.gtk.org/mailinglists.html - -To subscribe: mail -s subscribe gtk-list-request@gnome.org < /dev/null -(Send mail to gtk-list-request@gnome.org with the subject "subscribe") - -Installation -============ - -See the file 'INSTALL' - -Notes about GLib 2.20 -===================== - -* The functions for launching applications (e.g. g_app_info_launch() + - friends) now passes a FUSE file:// URI if possible (requires gvfs - with the FUSE daemon to be running and operational). With gvfs 2.26, - FUSE file:// URIs will be mapped back to gio URIs in the GFile - constructors. The intent of this change is to better integrate - POSIX-only applications, see bug #528670 for the rationale. The - only user-visible change is when an application needs to examine an - URI passed to it (e.g. as a positional parameter). Instead of - looking at the given URI, the application will now need to look at - the result of g_file_get_uri() after having constructed a GFile - object with the given URI. - -Notes about GLib 2.18 -===================== - -* The recommended way of using GLib has always been to only include the - toplevel headers glib.h, glib-object.h and gio.h. GLib enforces this by - generating an error when individual headers are directly included. - To help with the transition, the enforcement is not turned on by - default for GLib headers (it is turned on for GObject and GIO). - To turn it on, define the preprocessor symbol G_DISABLE_SINGLE_INCLUDES. - -Notes about GLib 2.16 -===================== - -* GLib now includes GIO, which adds optional dependencies against libattr - and libselinux for extended attribute and SELinux support. Use - --disable-xattr and --disable-selinux to build without these. - -Notes about GLib 2.10 -===================== - -* The functions g_snprintf() and g_vsnprintf() have been removed from - the gprintf.h header, since they are already declared in glib.h. This - doesn't break documented use of gprintf.h, but people have been known - to include gprintf.h without including glib.h. - -* The Unicode support has been updated to Unicode 4.1. This adds several - new members to the GUnicodeBreakType enumeration. - -* The support for Solaris threads has been retired. Solaris has provided - POSIX threads for long enough now to have them available on every - Solaris platform. - -* 'make check' has been changed to validate translations by calling - msgfmt with the -c option. As a result, it may fail on systems with - older gettext implementations (GNU gettext < 0.14.1, or Solaris gettext). - 'make check' will also fail on systems where the C compiler does not - support ELF visibility attributes. - -* The GMemChunk API has been deprecated in favour of a new 'slice - allocator'. See the g_slice documentation for more details. - -* A new type, GInitiallyUnowned, has been introduced, which is - intended to serve as a common implementation of the 'floating reference' - concept that is e.g. used by GtkObject. Note that changing the - inheritance hierarchy of a type can cause problems for language - bindings and other code which needs to work closely with the type - system. Therefore, switching to GInitiallyUnowned should be done - carefully. g_object_compat_control() has been added to GLib 2.8.5 - to help with the transition. - -Notes about GLib 2.6.0 -====================== - -* GLib 2.6 introduces the concept of 'GLib filename encoding', which is the - on-disk encoding on Unix, but UTF-8 on Windows. All GLib functions - returning or accepting pathnames have been changed to expect - filenames in this encoding, and the common POSIX functions dealing - with pathnames have been wrapped. These wrappers are declared in the - header which must be included explicitly; it is not - included through . - - On current (NT-based) Windows versions, where the on-disk file names - are Unicode, these wrappers use the wide-character API in the C - library. Thus applications can handle file names containing any - Unicode characters through GLib's own API and its POSIX wrappers, - not just file names restricted to characters in the system codepage. - - To keep binary compatibility with applications compiled against - older versions of GLib, the Windows DLL still provides entry points - with the old semantics using the old names, and applications - compiled against GLib 2.6 will actually use new names for the - functions. This is transparent to the programmer. - - When compiling against GLib 2.6, applications intended to be - portable to Windows must take the UTF-8 file name encoding into - consideration, and use the gstdio wrappers to access files whose - names have been constructed from strings returned from GLib. - -* Likewise, g_get_user_name() and g_get_real_name() have been changed - to return UTF-8 on Windows, while keeping the old semantics for - applications compiled against older versions of GLib. - -* The GLib uses an '_' prefix to indicate private symbols that - must not be used by applications. On some platforms, symbols beginning - with prefixes such as _g will be exported from the library, on others not. - In no case can applications use these private symbols. In addition to that, - GLib+ 2.6 makes several symbols private which were not in any installed - header files and were never intended to be exported. - -* To reduce code size and improve efficiency, GLib, when compiled - with the GNU toolchain, has separate internal and external entry - points for exported functions. The internal names, which begin with - IA__, may be seen when debugging a GLib program. - -* On Windows, GLib no longer opens a console window when printing - warning messages if stdout or stderr are invalid, as they are in - "Windows subsystem" (GUI) applications. Simply redirect stdout or - stderr if you need to see them. - -* The child watch functionality tends to reveal a bug in many - thread implementations (in particular the older LinuxThreads - implementation on Linux) where it's not possible to call waitpid() - for a child created in a different thread. For this reason, for - maximum portability, you should structure your code to fork all - child processes that you want to wait for from the main thread. - -* A problem was recently discovered with g_signal_connect_object(); - it doesn't actually disconnect the signal handler once the object being - connected to dies, just disables it. See the API docs for the function - for further details and the correct workaround that will continue to - work with future versions of GLib. - -How to report bugs -================== - -Bugs should be reported to the GNOME bug tracking system. -(http://bugzilla.gnome.org, product glib.) You will need -to create an account for yourself. - -In the bug report please include: - -* Information about your system. For instance: - - - What operating system and version - - For Linux, what version of the C library - - And anything else you think is relevant. - -* How to reproduce the bug. - - If you can reproduce it with one of the test programs that are built - in the tests/ subdirectory, that will be most convenient. Otherwise, - please include a short test program that exhibits the behavior. - As a last resort, you can also provide a pointer to a larger piece - of software that can be downloaded. - -* If the bug was a crash, the exact text that was printed out - when the crash occured. - -* Further information such as stack traces may be useful, but - is not necessary. - -Patches -======= - -Patches should also be submitted to bugzilla.gnome.org. If the -patch fixes an existing bug, add the patch as an attachment -to that bug report. - -Otherwise, enter a new bug report that describes the patch, -and attach the patch to that bug report. - -Bug reports containing patches should include the PATCH keyword -in their keyword fields. If the patch adds to or changes the GLib -programming interface, the API keyword should also be included. - -Patches should be in unified diff form. (The -u option to GNU -diff.) -- 2.7.4