* INSTALL: Update.
svn: r4510
This commit is contained in:
Alex Roitman
parent
d43dec5fd6
commit
207b811658
@ -1,3 +1,6 @@
|
|||||||
|
2005-05-06 Alex Roitman <shura@gramps-project.org>
|
||||||
|
* INSTALL: Update.
|
||||||
|
|
||||||
2005-05-07 Julio Sanchez <jsanchez@users.sourceforge.net>
|
2005-05-07 Julio Sanchez <jsanchez@users.sourceforge.net>
|
||||||
* src/po/es.po: Updated translation
|
* src/po/es.po: Updated translation
|
||||||
|
|
||||||
|
|||||||
104
gramps2/INSTALL
104
gramps2/INSTALL
@ -1,71 +1,53 @@
|
|||||||
For rebuilding from source, here are some guidelines to follow. For
|
$Id$
|
||||||
developers who may be adding functionality to the program, be sure to read
|
|
||||||
the last section of this documen: "FINAL WORDS".
|
|
||||||
|
|
||||||
SUPER-SHORT VERSION:
|
This file contains some useful details on the installation from source code
|
||||||
You should be able to just run "./configure && make". But if you make any
|
for GRAMPS. It does not cover installation of a pre-built binary package.
|
||||||
significant changes or experience any problems, you may wish to run
|
For that use your package manager, the rest is done by the packager.
|
||||||
"./autogen.sh && make" to regenerate everything.
|
|
||||||
|
|
||||||
This will call aclocal if necessary, then automake, which creates
|
|
||||||
Makefile.in from Makefile.am rules. Then it calls autoconf, which will
|
|
||||||
generate configure from configure.in and the Makefile.{am,in} sources.
|
|
||||||
Finally, autogen calls configure to generate the final files necessary for
|
|
||||||
building gramps.
|
|
||||||
|
|
||||||
SHORT VERSION:
|
configure vs autogen scripts
|
||||||
Execute:
|
----------------------------
|
||||||
aclocal
|
If you are building from released tarball, you should be able to just
|
||||||
automake --add-missing --gnu && autoconf && make
|
run "./configure && make". However, if you're building from the CVS,
|
||||||
|
the configure is not present. You should auto-generate it by
|
||||||
|
running ./autogen.sh and then "make" and, finally, "make install".
|
||||||
|
|
||||||
MORE INFO: Version and package info is now set in configure.in through a
|
|
||||||
call to the AM_INIT_AUTOMAKE macro. The results are stored in variables
|
|
||||||
PACKAGE and VERSION, which then get substituted wherever necessary.
|
|
||||||
(gramps.sh, gramps.spec, src/const.py, asst. Makefiles, etc.) We also
|
|
||||||
manually set the RELEASE variable for setting things like "pre" or minor
|
|
||||||
bugfix issues. * Note: Using @VERSION@ in the manuals has the advantage that
|
|
||||||
the current manual always states that it describes current version of
|
|
||||||
gramps. The disadvantage is that this becomes misleading if the manual
|
|
||||||
isn't regularly updated. Keep in mind this is GRAMPS version and not
|
|
||||||
*manual* version. Another problem is that the standard GNOME SGML
|
|
||||||
documentation make rules (sgmldocs.make) have their own rule, but automake
|
|
||||||
generates its own rule and this introduces a conflict.
|
|
||||||
|
|
||||||
"make (un)install" now runs scrollkeeper-update to ensure
|
Regular vs local installation
|
||||||
documentation database is up to date. Scrollkeeper v. > 0.3 is required
|
-----------------------------
|
||||||
to properly register documentation.
|
This version of gramps requires, among others, the two things to be done:
|
||||||
|
gconf schemas and mime types for gramps MUST be properly installed.
|
||||||
|
The usual ./configure, make, and make install as a root should do the trick.
|
||||||
|
But be careful if you're using the non-default options or would like
|
||||||
|
to install without being root.
|
||||||
|
|
||||||
VERBOSE, UGLY DETAILS FOR DEVELOPERS:
|
The latter is possible, but you should supply additional arguments to
|
||||||
Using automake/autoconf adds many, MANY build targets to the makefiles.
|
autogen or configrue:
|
||||||
Basically, we only care about the main and "install" targets. However,
|
--with-gconf-source=xml::$HOME/.gconf --with-mime-dir=$HOME/.local/share
|
||||||
there are some others that bear further notice:
|
Most likely, such local install will also need some prefix with write
|
||||||
|
permissions for you:
|
||||||
|
--prefix=$HOME/my_gramps_path
|
||||||
|
|
||||||
* make dist -- will create a lovely gramps-{VERSION}.tar.gz archive with
|
Whether you're doing local install or regular install, YOU MUST INSTALL
|
||||||
everything needed to distribute, including the HTML documentation just in
|
GCONF SCHEMAS AND MIME TYPES. YOU HAVE BEEN WARNED!
|
||||||
case Joe User doen't know about or have a compatable jw/db2html. After
|
|
||||||
running "make dist" you can create the rpms using
|
|
||||||
"rpm -ta gramps-{VERSION}.tar.gz". How nice is that?
|
|
||||||
|
|
||||||
* make clean -- only gets rid of byte-compiled stuff like .so files.
|
|
||||||
|
|
||||||
* make distclean -- improves on clean by eliminating configuration (*.in,
|
Packager's issues
|
||||||
config.*, Makefiles, and converted documentation.) stuff. This is generally
|
------------------
|
||||||
what you (as a developer) will want for testing "fresh" compiles.
|
The above mentioned gconf schemas and mime types must be installed.
|
||||||
|
However, the update-mime-database and the gconftool-2 calls to process
|
||||||
|
the newly installed types and schemas must be done in POST-INSTALLATION.
|
||||||
|
In packager's world, the install happens on packager's machine
|
||||||
|
into something like /tmp/gramps-tmp. However, the postinstall
|
||||||
|
should happen on the user's machine.
|
||||||
|
|
||||||
* make trans -- We add this one on our own for building the template.po file.
|
To assist with that, there's an argument available in configure
|
||||||
|
(or autogen, which will pass it to configure) which disables
|
||||||
Another caveat of the automake mantra is that new/overriding make
|
the gconf schema and mime type processing:
|
||||||
targets/rules/defines should generally go in the Makefile.am files rather
|
--enable-packager-mode
|
||||||
than Makefile.in.
|
This argument should disable postinstall calls made during
|
||||||
|
make install, and print a nasty warning during configure.
|
||||||
* Note: Another beauty of the automake mechanism (and having automake macros
|
IT IS PACKAGER'S RESPONSIBILITY to follow the advice given
|
||||||
in the configure script) is that once the scripts have been made, a change
|
by the configure output and to copy the appropriate code
|
||||||
to any .am file will trigger "make" to regenerate the Makefile.in/configure
|
from the src/data/Makefile.am into the pos-tinstall (and post-uninstall)
|
||||||
scripts as appropriate. It is _very_ convenient.
|
of the particular packaging system.
|
||||||
|
|
||||||
FINAL WORDS: automake "thinks" of a distribution in terms of "SOURCES", such
|
|
||||||
as raw C code, "COMPILED OBJECTS" like executables and libraries, and
|
|
||||||
"DATA", such as images, scripts, and documentation. Thus, for gramps we
|
|
||||||
concentrate on DATA-type objects. We must tell automake what objects are
|
|
||||||
important. We do this by adding to the EXTRA_DIST variable in the various
|
|
||||||
Makefile.am files before running automake.
|
|
||||||
|
|||||||
Loading…
x
Reference in New Issue
Block a user