Does Morgan run "make cleanall" too often? Probably. Except I actually run "git clean -xfd" because I don't trust "make cleanall". My background (which I do seem to bring up a lot) is packaging other people's projects for a reproducible computing platform (GNU Guix). This means I inherently don't trust people's Makefile (because they are usually bad (because Makefile syntax is confusing and weird (because shell syntax is confusing and weird (because backwards compatibility and universal standards are really nice so we can't really change it now)))).
Also, I often build org-mode in the GNU Guix build environment instead of the messy stateful place that is my local repo. This inherently involves starting from a clean slate. I have detailed my own idiosyncrasies in an attempt to show that not all developers will follow the expected build procedures. I would argue that accommodating these developers is important. I think code that is robust enough to be compiled in different ways or different environments is a good thing and can help with code quality and checks. I might be a little biased here though. Anyways lets get down to buisness and figure out our next steps. >> It looks like there isn't a good way to make use of >> `package-directory-list' unless you want to try something really funky >> like what is done in `testing/org-batch-test-init.el'. >> >> I guess I'll revert the package-directory-list changes > > Yeah. > I think we can introduce something similar to BTEST_POST, so that people > can direct Org to specific lisp directory. Maybe even dedicated variable > like USE_EMACS_D or similar to explicitly make Org include user > user-emacs-directory. WDYT? Seems like an easy thing to add. Might as well. Maybe we should have a "EMACS_LOAD_PATH" and "EMACS_LOAD_PATH_EXTRA" variable. > I think modules could be doable. > We can hide all the gory details under make targets, similarly to what > we do in the patch now. Then, instead of pulling compat from elpa, we > can sync the relevant git module. > I imagine that not touching that submodule except during version bumps > can help. It can be done via make target, similar to how we do ~make update~. > My usual frustration with git modules is when I have to go google yet > again how to fetch them should be addressed that way :) I'm liking this idea more and more. Required git submodules are really annoying because it adds another layer of friction to first build that I feel like git should be smart enough to do for me. However, this is an optional git module so now the git defaults actually make sense in this case. If we don't meet the required dependencies then my "org-dependencies.el" script will be able to communicate to the user what commands to run (just as it currently tells the user to run "uppkg"). So no google required! When we do a version bump we will also increase the version number that is checked in my "org-dependencies.el" script so the user will once again be prompted with what commands they need to run. The only downside I could conceive of is if a user uses the git submodule to build org and then runs that byte-code locally on their system with their system compat which could be of a different version. Honestly even if people do this they are unlikely to experience any negative effects. The ideal solution would be for those people to build with "EMACS_LOAD_PATH_EXTRA" set as mentioned earlier. >> If the code is downloaded as tarball, I strongly recommend to check it >> against a sha256 hash. See for instance: >> >> https://github.com/minad/doom-on-emacs/blob/9d5929335c4080699a2daa153ace2996c905008a/Makefile#L17 >> >> This way you would get similar guarantees. > > That would correspond to setting `package-check-signature' to t in the patch. Do we trust git fetch? If I go ahead with a submodule approach do I have to worry about this?
