GEPS 026: Replace 'make' for Gramps build
- The core Gramps developers do not know GNU Make, which was the case also in the past. Somebody of a company with expertise contributed the make system to Gramps. (Actually, I'm pretty fluent with autotools. John Ralls)
- With GNU Make developers need to update makefiles when adding and changing files.
*With setup.py developers only need to worry about changing directories; this is simpler to maintain.
- 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.
- 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
We need to create a setup.cfg file which defines the following:
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 14549 requests an enhancement to this functionality.
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 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.
A list of scripts. Just gramps.sh in our case.
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.
distutils2 provides support for customisation via command hooks. Our translation build code should be run via a build command hook. This should allow us to access the build directory and add files to the 'resources' as necessary.
- PEP 345: Metadata for Python Software Packages 1.2
- PEP 376: Database of Installed Python Distributions
- PEP 386: Changing the version comparison module in Distutils
- PEP 390: Static metadata for Distutils
- 5302: Allow package_data specs/globs to match directories
- 8501: --dry-run option doesn't work
- 12830: --install-data doesn't effect resources destination
- 12393: Packaging should provide support for extensible categories
- 13463: Fix parsing of package_data
- 14549: Recursive inclusion of packages
- 14651: pysetup run cmd can't handle option values in the setup.cfg