[glib] remove generated files

From: Matthias Clasen <matthiasc src gnome org>
To: svn-commits-list gnome org
Subject: [glib] remove generated files
Date: Thu, 2 Apr 2009 23:16:25 -0400 (EDT)
commit b160405aa0a66f3eb771af43b6d0000d076d045b
Author: Matthias Clasen <mclasen redhat com>
Date:   Thu Apr 2 23:13:35 2009 -0400

    remove generated files
    
    README and INSTALL are generated files, no need to keep them
    under source control.
---
 INSTALL |  116 -------------------------------------
 README  |  199 ---------------------------------------------------------------
 2 files changed, 0 insertions(+), 315 deletions(-)

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 <glib/gstdio.h> which must be included explicitly; it is not
-  included through <glib.h>.
-
-  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.)
[Date Prev][Date Next] [Thread Prev][Thread Next] [Thread Index] [Date Index] [Author Index]