123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172 |
- Requirements
- ------------
- If you want to hack on the GIMP project, it will make your life easier
- to have the following packages (or newer versions) installed:
- * GNU autoconf 2.54
- - ftp://ftp.gnu.org/gnu/autoconf/
- * GNU automake 1.9 (automake 1.8 should also work)
- - ftp://ftp.gnu.org/gnu/automake/
- * GNU libtool 1.4 (libtool 1.5 if you are compiling on Win32)
- - ftp://ftp.gnu.org/gnu/libtool/
- Fine GNU mirrors are listed at http://www.gnu.org/prep/ftp.html
- Beta software can be found at alpha.gnu.org.
- * pkg-config 0.15.0 (or preferably a newer version)
- - http://www.freedesktop.org/software/pkgconfig/
- * intltoolize 0.31.1 (or preferably a newer version)
- - ftp://ftp.gnome.org/pub/gnome/sources/intltool/
- * gtkdocize
- - http://ftp.gnome.org/pub/GNOME/sources/gtk-doc/
- * xsltproc
- - ftp://ftp.gnome.org/pub/GNOME/sources/libxslt/1.1/
- These are only the additional requirements if you want to compile from
- CVS. The file INSTALL lists the various libraries we depend on.
- Compilation
- -----------
- If you are accessing gimp via CVS, then you will need to take several
- steps to get it to compile. You can do all these steps at once
- by running:
- cvsroot/gimp$ ./autogen.sh
- Basically this does the following for you:
- cvsroot/gimp$ aclocal-1.9; libtoolize; automake-1.9 -a;
- cvsroot/gimp$ autoconf; glib-gettextize; intltoolize
- The above commands create the "configure" script. Now you can run the
- configure script in cvsroot/gimp to create all the Makefiles.
- Before running autogen.sh or configure, make sure you have libtool in
- your path. Also make sure glib-2.0.m4 glib-gettext.m4, gtk-2.0.m4,
- pkg.m4 and intltool.m4 are either installed in the same
- $prefix/share/aclocal relative to your automake/aclocal installation
- or call autogen.sh as follows:
- $ ACLOCAL_FLAGS="-I $prefix/share/aclocal" ./autogen.sh
- Note that autogen.sh runs configure for you. If you wish to pass
- options like --prefix=/usr to configure you can give those options to
- autogen.sh and they will be passed on to configure.
- If AUTOGEN_CONFIGURE_ARGS is set, these options will also be passed to
- the configure script. If for example you want to enable the build of
- the GIMP API reference manuals, you can set AUTOGEN_CONFIGURE_ARGS to
- "--enable-gtk-doc". Please note that you will then need a recent
- version of gtk-doc as well as a working setup for handling DocBook/XML.
- If you do not have a recent version of gtk-doc, you can pass the
- option "--disable-gtk-doc" to autogen.sh. This will completely
- disable the support for gtk-doc so you will not be able to generate
- the API documentation.
- CVS
- ---
- GIMP is available from GNOME CVS. You can also grab glib, pango, atk,
- gtk+, libart, gtkhtml2 as well as intltool and gtk-doc from the same
- CVS server. You can use the following commands to get them from the
- anonymous CVS server:
- $ export CVSROOT=':pserver:anonymous@anoncvs.gimp.org:/cvs/gnome'
- $ cvs login
- (there is no password, just hit return)
- $ cvs -z3 checkout [-r <branch>] <module>
- The interesting modules and the suggested stable branches to use are:
- * gimp
- * glib (glib-2-8)
- * atk (gnome-2-12)
- * pango (pango-1-10)
- * gtk+ (gtk-2-8)
- * libart_lgpl
- * gtkhtml2
- * intltool
- * gtk-doc
- Patches
- -------
- The best way to submit patches is to file a bug report at
- http://bugzilla.gnome.org/ and attach your patch to it as a plain text
- file, not compressed. If your patch is reasonably small you can submit
- it to the gimp-developer@lists.xcf.berkeley.edu mailing list. If the
- patch needs to be discussed, you should also consider using the
- mailing list instead of Bugzilla because bug reports tend to be hard
- to read if they contain too many comments. For the code, please try to
- follow the guidelines given in Hackordnung, below. You can create the
- patch file with "cvs diff", preferably with a ~/.cvsrc containing
- "diff -up". All kinds of contributions are appreciated.
- Autogenerated Files
- -------------------
- Please notice that some files in the source are generated from other
- sources. All those files have a short notice about being autogenerated
- somewhere at the top. Among them are the files ending in _pdb.[ch] in
- the libgimp directory and the files ending in _cmds.c in the app/pdb
- subdirectory. Those are generated from the respective .pdb files in
- tools/pdbgen/pdb. The list of contributors is used in several files
- which are for that reason generated from the file contributors in
- tools/authorsgen.
- Hackordnung
- -----------
- We encourage you to follow the GIMP coding style throughout the GIMP
- project. For the core components (application and libs) this coding
- style is enforced. The GIMP coding style is defined as follows:
- * There's a single space between the function name and the opening
- paren.
- * Function names are lowercase, words separated by underscores.
- * Macros and enums are all uppercase, words seperated by
- underscores.
- * Types are all words capitalized, no separators between words.
- * All functions in header files need to be prototyped.
- * Indentation rules are GNU coding style, in particular:
- - 2 characters indentation level
- - Do not use tabs (of course your editor can accept the TAB key
- as a command, typically to indent the current line properly
- or to add spaces at the cursor until the next multiple of 8
- columns, but it should not put TAB characters in the file).
- - When editing files that still have TABs in them, make sure your
- editor interprets the TABs correctly, that is, has tab stops
- at 8 column intervals.
- - Opening braces are on a new line and indented one level.
- - Function header have the return type on one line, the name
- starting in the first column of the following line. All
- parameters are prototyped and there's a new line for each.
- Try to make use of GLib's object system as much as possible. Do not
- create wrappers around functions of parent classes. If you end up
- duplicating code, try to create a common parent class and implement
- the common methods there.
- Don't include headers in headers except where unavoidable (e.g. for
- deriving objects). Opaque typedefs go to app/base/base-types.h,
- app/core/core-types.h etc. See devel-docs/includes.txt for a
- detailed description of the include policy.
- Don't use the GTK wrappers around the GLib object and signal system.
- One goal of GIMP development is to make the GIMP code more readable
- and understandable. Please help us to achieve this goal by cleaning up
- the present code and make sure that all new code follows the coding
- guidelines.
|