Hi,
I think there is a bug in transfig, when asking for a pdftex makefile. The "all" target depends on a pdftex extension which has no rule to build, resulting in "No rule to make..."
MACHINE/OS:
Linux 4.19.0-1-amd64 #1 SMP Debian 4.19.12-1 (2018-12-22) x86_64 GNU/Linux
VERSIONS:
transfig(fig2dev) Version 3.2.7a
GNU Make 4.2.1
DESCRIPTION:
Launching "transfig -L pdftex ALU.fig" generates the attached Makefile.
As it can be seen in the attachment, there is no rule to build "ALU.pdftex".
Since xfig version 3.2.7a exports to "Combined PDF/LaTeX (both parts)" using files with extensions .pdf and .pdf_t, probably transfig should use the same naming conventions.
Therefore, Makefile should contain the line:
all: ALU.pdf_t
instead of:
all: ALU.pdftex
Also, Makefile should contain the lines:
ALU.pdf_t: ALU.pdf Makefile
fig2dev -L pdftex_t -p ALU.pdf ALU.fig ALU.pdf_t
instead of:
ALU.tex: ALU.pdf Makefile
fig2dev -L pdftex_t -p ALU.pdf ALU.fig ALU.tex
Thanks for your interest in xfig and its companion programs.
Concerning transfig: I have to admit, that I never really understood the usefulness of transfig. To me, it always seemed easier to directly invoke fig2dev, instead of generating a quite rudimentary Makefile. Could you post your opinion on transfig?
Actually, I have never used transfig nor fig2dev. I always exported directly from xfig, sharing the exported versions if needed. However, recently I've been working on shared documents through gitlab, and using its continuous integration capabilities to build the documents on each push to ensure that they build correctly. Thus, ideally, exporting fig files should be part of this building process. So, transfig was my first option to try.
I really don't know if transfig is what I need. Writing my own Makefile should be trivial, and it would allow much more details than transfig. Nevertheless, it is always a good idea to test whether a problem can be solved with existing tools.