7

In the pgfmanual I found today under Section 50.4.4 Customizing the Externalization that you can have multicore support during externalization using the mode list and make.

% step 1: generate main.makefile:
pdflatex main
% step 2: generate ALL graphics on 2 processors:
make -j 2 main.makefile
% step 3: include the graphics:
pdflatex main

I am using Windows 7 and MiKTeX. Since I never used make I downloaded it here: http://www.gnu.org/software/make/. Then I used this MWE (main.tex):

\documentclass{article}

\usepackage{tikz,pgfplots}
\usetikzlibrary{external}
% Important
\tikzexternalize[mode=list and make]

\begin{document}

\begin{tikzpicture}
  \begin{axis}
    \addplot coordinates {(0,0) (1,1) (4,4)};
  \end{axis}
\end{tikzpicture}

\end{document}

So I used a batch file like the pgfmanual said:

% step 1: generate main.makefile:
pdflatex main
% step 2: generate ALL graphics on 2 processors:
make -j 2 main.makefile
% step 3: include the graphics:
pdflatex main

But it doesnt' work. I get a message during the make -j 2 main.makefile part:

make: Nothing to be done for 'main.makefile'

Then I used make -f main.makefile like it was suggested during the first pdflatex main and I get:

process_begin: CreateProcess(NULL, cat main.figlist, ...) failed.
process_begin: CreateProcess(NULL, cat main.figlist, ...) failed.

Here a screenshot for the make part:

enter image description here

This is how the make file looks like:

ALL_FIGURE_NAMES=$(shell cat main.figlist)
ALL_FIGURES=$(ALL_FIGURE_NAMES:%=%.pdf)

allimages: $(ALL_FIGURES)
    @echo All images exist now. Use make -B to re-generate them.

FORCEREMAKE:

include $(ALL_FIGURE_NAMES:%=%.dep)

%.dep:
    mkdir -p $(dir $@)
    touch $@ # will be filled later.

main-figure0.pdf: 
    pdflatex -halt-on-error -interaction=batchmode -jobname "main-figure0" "\def\tikzexternalrealjob{main}\input{main}"

main-figure0.pdf: main-figure0.md5

main-figure0.pdf is not generated -- but main-figure0.md5 is generated.

Update (Christian's Answer)

I tried your advice (ALL_FIGURE_NAMES=main-figure0) and replaced the code in the makefile but it still doesn't work.

enter image description here

I voted to close the question. It seems that only I have the problem. Thanks for the help!

  • I was about to answer that the list and make option was probably not intended to be run on windows at all, but the $(dir $@) line tends to prove otherwise. Have you tried from an administrator console? – T. Verron May 30 '14 at 11:11
  • make -j 2 main.makefile : this probably didn't work because you miss the -f flag before the name of the makefile. And the .md5 files are generated during the first run of pdflatex. – T. Verron May 30 '14 at 11:14
  • Hello. Thanks for the hints. I also tried it with administrator rights and with adding the missing -f flag. No luck. Can you guys confirm the error on Windows? – Dr. Manuel Kuehner May 30 '14 at 12:08
  • Apparently it is a known bug since a few years now (I haven't been able to find any binary more recent than 2006). If recompiling from the source is possible for you, you can try the patch described here: http://lists.gnu.org/archive/html/make-w32/2008-03/msg00008.html – T. Verron May 30 '14 at 12:35
  • Thanks. That is way beyond my capabilities. But good to know that's not because I did it wrong. So should I delete or close this question somehow? – Dr. Manuel Kuehner May 30 '14 at 12:42
  • 3
    It seems to narrow. Apparently other people don't have my problem. – Dr. Manuel Kuehner May 31 '14 at 17:45
  • @T.Verron dir is a command on other systems, too. I have it, for example, and I am no Windows user! It is part of GNU coreutils according to the manual page. – cfr Jul 29 '16 at 02:16
  • @cfr My bad, I should have double-checked before posting. Sadly I'm a bit out of the 5-minute window for comment edition. ;) – T. Verron Jul 29 '16 at 03:03
  • 1
    @T.Verron ;) Sometimes the site restrictions just strike me as silly. You could delete your comment at any time but God forbid you should be allowed to correct it! – cfr Jul 29 '16 at 03:15
  • @T.Verron I think you are right but not for the reason you gave. GNU make is supported on W32. Just the evidence you gave doesn't probably justify that conclusion, which just happens to be true. The issue, it seems to me, is that the process needs make and make is not default on all platforms. (But I don't know if there's a better option.) – cfr Jul 29 '16 at 03:57

1 Answers1

3

This is actually a typo in the pgf manual:

You need the -f option, i.e. it has to be

% step 1: generate main.makefile:
pdflatex main
% step 2: generate ALL graphics on 2 processors:
make -j 2 -f main.makefile
% step 3: include the graphics:
pdflatex main

It has already been corrected some time ago and will become part of the next PGF release.


Regarding your make problems with "CreateProcess failed" :

  1. you can try to install cygwin and call make from within cygwin. difficulty: medium (unless you are familiar with linux shells)
  2. you can copy the makefile to some other name and modify it manually. To this end, substitute

    ALL_FIGURE_NAMES=$(shell cat main.figlist)

by

ALL_FIGURE_NAMES=main-figure0 main-figure1 main-figure2

etc. The file list should resemble the content of main.figlist. You would need to update this copy of the makefile whenever a new item arrives, but it should work.

  • Thanks. But the error remains: 'process_begin: CreateProcess(NULL, cat main.figlist, ...) failed.' Btw - is the 'external/optimize=false' new? Because my file (about 6 months old) didn't compile anymore and I had to add 'optimize=false' in order to export the plots. – Dr. Manuel Kuehner May 30 '14 at 13:05
  • I should have read the comment more carefully. Perhaps gnu make does not work without cygwin :-( Installing cygwin, however, is also more of an advanced topic – Christian Feuersänger May 30 '14 at 13:11
  • external/optimize is very old... can you take a look into the log files of the failing images (P-figure0.log or something like that) and pose a new question regarding the compile failures? – Christian Feuersänger May 30 '14 at 13:14
  • @ChristianFeuersänger : The gmane link I posted above mentions a bug with the $(shell ...) directives in win32 make. The thread is dated from 2008 and the last release I could find was 2006. Thus the problem seems unlikely to be related to tikz. – T. Verron May 30 '14 at 13:37
  • interesting. I have edited my answer. – Christian Feuersänger May 30 '14 at 13:59
  • I may be wrong, but the 2nd method will never work in a guaranteed way on Windows, since the main.makefile wasn't written for this OS, even if you install make somehow. I have never programmed a makefile, but in order to get rid of errors and have an "executable" makefile on Windows I took some risks and got the following after many attempts: (Sorry, I had to split it in two comments) NOTE: I’m pretty sure that these modifications are wrong because I don’t know what I am doing. >>>> – Leone Mar 09 '21 at 08:07
  • (continuation)>>>> I installed make (source), changed cat by type (source), changed mkdir -p "$(dir $@)" by mkdir "$(dir $@)" (source), and changed touch "$@" # will be filled later. by shell $($null >> "$@") (source). In doing so, the copied makefile seems to do the job for most cases (the very first run still leads to an error, but the others don’t), however, its behavior is unreliable. – Leone Mar 09 '21 at 08:08