# The core Gramps developers do not know [http://www.gnu.org/software/make/ GNU Make], which was the case also in the past. Somebody of a company with expertise contributed the make system to Gramps.

+

# The core Gramps developers do not know [http://www.gnu.org/software/make/ GNU Make], which was the case also in the past. Somebody of a company with expertise contributed the make system to Gramps. ([http://gramps.1791082.n4.nabble.com/prepare-gramps-3-4-tp4329757p4613312.html Actually, I'm pretty fluent with autotools. John Ralls])

−

# With GNU Make developers need to update makefiles when adding and changing files.<br />*With setup.py developers only need to worry about changing directories; this is simpler to maintain.

+

# With GNU Make developers need to update makefiles when adding and changing files.<br />*With setup.cfg/ DistUtils2, developers only need to worry about is creating quality Python code. Searching and adding files to Makefiles is no longer needed as it is handled dynamically now.

# With GNU Make from time to time it happens that a new file is forgotten to be added in a release, causing maintainance overhead for the release manager.

# With GNU Make from time to time it happens that a new file is forgotten to be added in a release, causing maintainance overhead for the release manager.

−

# Gramps is pure python, we don't need a makefile system checking for a lot of things it is checking now.

+

# Gramps is pure python, we don't need a makefile system checking for a lot of things it is checking for now.

# We need less dependencies for installing Gramps in linux.<br />*''Already on windows makefiles are not used.''

# We need less dependencies for installing Gramps in linux.<br />*''Already on windows makefiles are not used.''

# An increasing number of projects that need GNU Make switch to [http://www.cmake.org/ CMake], ..., we should not stay with old technology just because it was already present

# An increasing number of projects that need GNU Make switch to [http://www.cmake.org/ CMake], ..., we should not stay with old technology just because it was already present

−

==Issues==

+

==Posibilities==

+

===Distutils===

+

Common way of distributing python. This is currently in gramps40 and trunk. It uses the setup.py and MANIFEST.in files.

+

+

To create a source distribution run:

+

+

python setup.py sdist

+

+

It creates a tar file in dist directory. It also creates a MANIFEST file that contains files in distribution.

+

+

To build run:

+

+

python setup.py build

+

+

Files are created in build directory.

+

+

To install run:

+

+

python setup.py install

+

+

For testing it is convenient to install to a different root directory and disable execution of post-install mime processing.

+

+

python setup.py install --root ~/test --enable-packager-mode

+

+

===Packaging (Distutils2)===

+

+

The way of the future. At this time it seems not ready yet for use in Gramps.

+

We need to create a setup.cfg file which defines the following:

+

+

*packages

+

+

A list of packages that should be installed in the gramps directory under python site-packages. This should be a list of all packages, but excluding test and experimental packages. We can generate this dynamically to ease maintenance. There is a function provided to do this.

+

+

Note: Issue [http://bugs.python.org/issue14549 14549] requests an enhancement to this functionality.

+

+

*package_data

+

+

A list of file specifications of all non-package files that should also be installed in the gramps directory under python site-packages. This should specify all files under the data, glade, images and plugins directories.

+

+

Note: Issues [http://bugs.python.org/issue5302 5302] and [http://bugs.python.org/issue13463 13463] cause a problem with this at the moment.

+

+

*resources

+

+

A list of file specifications of files that need to be installed outside the gramps directory under python site-packages. Targets for files include 'categories' which are OS independent.

+

+

Note: Issue [http://bugs.python.org/issue12393 12393] requests support for extensible categories which could be useful to us.

+

+

*scripts

+

+

A list of scripts. Just gramps.sh in our case.

+

+

*extra_files

+

+

A list of file specifications of files that need to be included in the distribution, but should not be installed. This provides an alternative to the MANIFEST.in file, and should be easier to maintain. Another alternative would be a 'manifest-builder', which we should investigate. This could automatically include all files that are under version control.

+

+

Note: Issue [http://bugs.python.org/issue14691 14691] prevents specifying a manifest builder in the config file. There is a patch available to fix this. This issue has been resolved/ closed on 2012-04-29.

+

+

distutils2 provides support for customisation via command hooks. Our translation build code, compiling manual page, and XDG files (gramps.desktop, gramps.keys, and gramps.xml), and (holidays.xml and tips.xml) files will be created by these command hooks in the correct sequences.

With GNU Make developers need to update makefiles when adding and changing files.*With setup.cfg/ DistUtils2, developers only need to worry about is creating quality Python code. Searching and adding files to Makefiles is no longer needed as it is handled dynamically now.

With GNU Make from time to time it happens that a new file is forgotten to be added in a release, causing maintainance overhead for the release manager.

Gramps is pure python, we don't need a makefile system checking for a lot of things it is checking for now.

We need less dependencies for installing Gramps in linux.*Already on windows makefiles are not used.

An increasing number of projects that need GNU Make switch to CMake, ..., we should not stay with old technology just because it was already present

Posibilities

Distutils

Common way of distributing python. This is currently in gramps40 and trunk. It uses the setup.py and MANIFEST.in files.

To create a source distribution run:

python setup.py sdist

It creates a tar file in dist directory. It also creates a MANIFEST file that contains files in distribution.

To build run:

python setup.py build

Files are created in build directory.

To install run:

python setup.py install

For testing it is convenient to install to a different root directory and disable execution of post-install mime processing.

python setup.py install --root ~/test --enable-packager-mode

Packaging (Distutils2)

The way of the future. At this time it seems not ready yet for use in Gramps.
We need to create a setup.cfg file which defines the following:

packages

A list of packages that should be installed in the gramps directory under python site-packages. This should be a list of all packages, but excluding test and experimental packages. We can generate this dynamically to ease maintenance. There is a function provided to do this.

A list of file specifications of all non-package files that should also be installed in the gramps directory under python site-packages. This should specify all files under the data, glade, images and plugins directories.

A list of file specifications of files that need to be installed outside the gramps directory under python site-packages. Targets for files include 'categories' which are OS independent.

Note: Issue 12393 requests support for extensible categories which could be useful to us.

scripts

A list of scripts. Just gramps.sh in our case.

extra_files

A list of file specifications of files that need to be included in the distribution, but should not be installed. This provides an alternative to the MANIFEST.in file, and should be easier to maintain. Another alternative would be a 'manifest-builder', which we should investigate. This could automatically include all files that are under version control.

Note: Issue 14691 prevents specifying a manifest builder in the config file. There is a patch available to fix this. This issue has been resolved/ closed on 2012-04-29.

distutils2 provides support for customisation via command hooks. Our translation build code, compiling manual page, and XDG files (gramps.desktop, gramps.keys, and gramps.xml), and (holidays.xml and tips.xml) files will be created by these command hooks in the correct sequences.