https://codereview.appspot.com/575960043/diff/557650043/make/lilypond-vars.make File make/lilypond-vars.make (right):
https://codereview.appspot.com/575960043/diff/557650043/make/lilypond-vars.make#newcode20 make/lilypond-vars.make:20: export PYTHONPATH:=$(top-build-dir)/python/$(outconfbase):$(PYTHONPATH) On 2020/04/06 19:50:35, hanwenn wrote: > On 2020/04/05 21:54:40, hahnjo wrote: > > On 2020/04/05 21:48:46, hanwenn wrote: > > > This will potentially make the out-www build fail. It's much better to load > > the > > > source files directly, because they're always there and they're always up to > > > date. > > > > I don't see why this should break: It's now back to the state it was before > you > > changed it. But I can change it to out/ if you prefer. > > Loading .py files from out/ directories is an antipattern in the lilypond build > that makes working on the scripts a PITA, because the dependency tracking > doesn't work, and you have to remember to rebuild them by hand. Please don't > reintroduce this. I don't really get that argument. As far as I understand, your recent change ensures that python/ is built first to get the modules before they are needed. AFAICT this dependency works correctly, and if you touch a .py file in the source directory it is correctly copied over and byte-compiled. Maybe you can describe what's an "antipattern" about this? https://codereview.appspot.com/575960043/diff/557650043/python/GNUmakefile File python/GNUmakefile (right): https://codereview.appspot.com/575960043/diff/557650043/python/GNUmakefile#newcode27 python/GNUmakefile:27: local-test: default On 2020/04/06 19:50:35, hanwenn wrote: > On 2020/04/05 21:54:40, hahnjo wrote: > > On 2020/04/05 21:48:46, hanwenn wrote: > > > if you do it like this, this should depend on $(outdir)/book_base_test.py > and > > > the rule should use $< . Otherwise, editing the test file doesn't redo the > > copy. > > > > No, default depends on $(OUT_PY_MODULES). And we really need all modules > because > > book_base_test.py includes other files. > > you're right. I do think that this is not the way to go to suppress the > __pycache__ directory. If that is a concern, we should just pass -B to the > commandline. It doesn't surpress __pycache__, it just uses the already compiled modules in the build directory. This way there is exactly one location where the cache is. https://codereview.appspot.com/575960043/
