"don't want it to necessarily use Makefiles"

Why the hey not Dr. Kitchin!?

Make is an extremely powerful language

Problem is people make makefiles that are often hard for others to
read--suggest you try hard to keep it simple & avoid the fancy ways of
doing things

Make has flow control & is a very rich language

I use makefiles for every project Then Ccc to compile and/or run
everything--in Emacs--can't get easier and faster than that--as long as you
make the makefiles so easy that anyone can read & understand exactly what
it does

This is my default, which I may edit on-the-fly and just put in another
project name:

make --ignore-errors --jobs=555 -w --keep-going --warn-undefined-variables
--environment-overrides -f ~/n/n/etc/1cv2tex2doc-project_mak.makefile
1cv2tex2doc-project-exe

All slightly interesting ways to improve make have failed slightly, in one
way or another--they catch on for a few years until they're mostly
abandoned--for very good reasons

Look at it this way: Is there anything wrong with make?  Where does it fail?

Everyone should learn & use make

--Brian G. Powell, M.S.--that guy that still loves Makefiles and still
loves using asterisks ("***") as bullets in OrgMode

On Sun, Jan 26, 2020 at 1:11 PM John Kitchin <jkitchin@andrew.cmu.edu>
wrote:

> Hi everyone,
>
> This is only semi-on-topic. I am looking for something like M-x compile
> for my org-files, but I don't want it to necessarily use Makefiles. I am
> looking for suggestions of existing solutions to this, or thoughts on how
> to implement this.
>
> Actually, if it was possible to get M-x compile to run an elisp function
> instead of a make file, it might be all I need, but it looks like it runs
> shell commands.
>
> For most of my files, simple exporting is totally adequate. But, some
> files are more complicated, and what I usually do in these cases is write
> an elisp code block in a section that is tagged :noexport: and then I run
> that block to build the result. A recent example was a proposal where I
> needed a pdf of the body, and separate pdf of the references.
>
> I have separate elisp functions that generate these, and then I added some
> custom cleanup code in the block to delete some intermediate directories. I
> don't want to put these in a makefile because they are specific to this
> document. While this works, in a large document I find it a little
> inconvenient to make a small change say at the top, and then to jump to the
> bottom to run the build block to see how it changed. What I would prefer is
> to just run a command like M-x org-compile that would know about this build
> block and run it. That block could of course be a shell block that runs a
> makefile, but it would most often be an elisp block. I could even imagine
> that there is a makefile block that is tangled before running a shell block
> that runs a make command.
>
> What I do in a function now is something like this in a save-excursion:
>
> (when (not (stringp (org-babel-goto-named-src-block "build")))
>       (org-babel-execute-src-block))
>
> I don't use this in these projects, but they highlight some of the
> complexities I am trying to simplify. These are book like projects with
> special formatting needs, and multiple outputs.
>
> In this project (
> https://github.com/jkitchin/pycse/blob/master/pycse.org#L15096), I have
> multiple output targets that I would run.
>
> In this project (
> https://github.com/jkitchin/dft-book/blob/master/dft.org#build) I use
> some temporary filters to save the src blocks to files, and to embed them
> in the pdf so they can be opened.
>
> Anyway, it feels like I am reinventing something here, and that there
> might be some better approach already out there. Maybe some elisp
> equivalent of a makefile or something?
>
> Thoughts?
>
> John
>
> -----------------------------------
> Professor John Kitchin
> Doherty Hall A207F
> Department of Chemical Engineering
> Carnegie Mellon University
> Pittsburgh, PA 15213
> 412-268-7803
> @johnkitchin
> http://kitchingroup.cheme.cmu.edu
>
>