On Mon, Sep 30, 2019 at 7:08 PM Dan Eble <d...@faithful.be> wrote: > The thought that gave rise to my question was that I would be more > comfortable collaborating if these changes were in git rather than a dozen > patches in multiple messages in the mailing list archive. (I don’t intend > that to sound mean.) >
I've been maintaining my work in https://github.com/MasterOdin/lilypond/tree/py3_future2, though I fear I squashed Jonas' patches into a singular commit between Knut's and my commits. However, I think before going further, it is important that the maintainers finalize what they would like to see in terms of python compatibility for LilyPond and GUB, though a fair number of the changes can be landed in upstream master and work on Python 2.4 as well (move to new style classes, change the string raise to the LilyError class, etc.), though some require a minimum of Python 2.6 (changes to exception handlers, __future__.print_function). I'd be happy to start putting together some patches and submitting them for review if that would be helpful in this effort, or if this effort is better directed somewhere else within the python infrastructure of LilyPond/GUB. > my principle test was that the targets finished without error > > . . . > > The stepmake stuff though is were I have no idea how to handle as I am > not sure exactly what its purpose/doing is. > > Is that pessimism? > Somewhat, though more at the bigger picture of that this makefile is far far more complex than the simple ones I've ever dealt with and trying to figure out the pieces of how it all fits together, plus the necessary modifications to get it cross version compatible. > If you want to discover whether the targets you are testing exercise the > rules in python-module-rules.make, you can insert a command that will fail > when you get there, e.g. > > $(outdir)/%.pyo: $(outdir)/%.py > false # DO NOT COMMIT > $(PYTHON) -O -c 'import py_compile; py_compile.compile ("$<")' > > If your tests are exercising those rules and nothing else seems to go > wrong, that should reduce your concern. > Sorry, I was unclear, should not have rushed to put that last email together as I was walking out the door. It's more accurate to say that I understand conceptually what that particular snipped does and how one could make it work on just Python 2 or Python 3.7, but I do not know one would approach making it work on both Python 2 and Python3.7 (and potentially other Python3 targets) and that I think it would be something in if statements in python-module-vars.make to be in pseudo-code: if python3: py_version = python -c "import sys; print(str(sys.version_info[0]) + str(sys.version_info[1]))" build_dir = $(outdir)/__pycache__ extension = .cpython-$(py_version).pyc else: build_dir = $(outdir) extension = .pyc with the build target being: $(build_dir)/%$(extension): $(outdir)/%.py - I briefly tried to convert that to actual make syntax, but was getting nowhere slowly, and have given up on that bit for now. Matt _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
