On Thu, Oct 21, 2010 at 09:23:52PM +0200, Elena ``of Valhalla'' wrote: > It would be very nice (for us lazy packagers) to be able to install > bugseverywhere using standard distutils instead of a custom makefile, > mostly because it would allow to use preexisting scripts and templates > instead of having to sed the hardcoded values in the Makefile.
Were you thinking of something more along the lines of http://stackoverflow.com/questions/1754966/how-can-i-run-a-makefile-in-setup-py or a translation into setup.py calls to distutils.dep_util.newer_group() distutils.spawn.spawn() distutils.util.execute() ? Can you explain what you mean by "preexisting scripts and templates"? > This is expecially nice when using a cross-compiling environment > like openembedded, where even for pure python there are various custom > locations and executables involved. If that is your only issue, I think it would be cleaner to leave everything in the Makefile and add more variables that you can override on invocation. For example, you can already do make RM=/path/to/your/custom/rm See http://www.gnu.org/software/make/manual/html_node/Overriding.html > Since using plain distutils for the release tarball would also > solve the issues with libbe/_version.py, The issues with libbe/_version.py are: * Development checkouts (i.e. git repos) should regenerate it for each build. * Release checkouts (i.e. unpacked tarballs) should contain a version generated by the releasing development checkout and not attempt to generate their own. We could do this statically in the Makefile with something along the lines of GIT_DIR = $(shell find . -name .git) ifeq (,$(GIT_DIR)) # release-specific code else # devel-specific code endif See http://www.gnu.org/software/make/manual/html_node/Conditionals.html#Conditionals but sed-ing the Makefile seems cleaner to me. It is unclear to me how a distutils approach to this problem would be simpler. > allowing this installation road by adding pregenerated documentation > would, imho, be a clean solution. By "pregenerated documentation" do you mean 1) Man page 2) Sphinx documentation a) html b) dirhtml c) pickle d) json ... I think its better to leave the documentation compilation up to the user/packager. For users/packagers who don't want to compile the docs, they are online: http://docs.bugseverywhere.org/ http://www.physics.drexel.edu/~wking/code/be/doc/ I've just added code to generate an HTML version of the man page, and posted the output: http://einstein.drexel.edu/~wking/code/be/doc/be.1.html so you don't even need to generate the man page if you don't want to. -- This email may be signed or encrypted with GPG (http://www.gnupg.org). The GPG signature (if present) will be attached as 'signature.asc'. For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy My public key is at http://www.physics.drexel.edu/~wking/pubkey.txt
pgpJGpiVcSySP.pgp
Description: PGP signature
_______________________________________________ Be-devel mailing list [email protected] http://void.printf.net/cgi-bin/mailman/listinfo/be-devel
