LuaLaTeX: automatizza la compilazione multipla con ToC, Indice, Bibliografia, Glossario e altri su CI
Per avere build riproducibili e affidabili di documenti su un sistema CI remoto, vorrei automatizzare tutti gli strumenti della riga di comando e le compilazioni multiple necessarie per produrre un documento completo. Questa pipeline dovrebbe funzionare su qualsiasi documento fuori dalla scatola, indipendentemente da quali plugin sono effettivamente utilizzati nel documento.
A quanto mi risulta, esiste un modo per una build LaTeX di eseguire automaticamente tutti i passaggi necessari, ma finora non ho avuto successo con alcun approccio.
Dettagli
La mia configurazione attuale è questa:
- I documenti vengono scritti e compilati sulla mia macchina utilizzando LuaLaTeX e MiKTeX
- L'elemento della configurazione è costituito dall'immagine Docker MiKTeX ( vedi qui ) con tutti i caratteri e le risorse personalizzati installati
A livello locale devo eseguire varie azioni in sequenza per compilare un documento che devo conoscere come autore di un documento. Ma l'elemento di configurazione dovrebbe essere in grado di creare qualsiasi documento senza applicare impostazioni speciali per documento e produrre errori quando il documento non può essere compilato correttamente o manca qualcosa.
Esempio: glossario
Quando ho bisogno di creare un documento in cui utilizzo il glossaries
pacchetto, la build locale sarebbe simile a questa
lualatex doc.tex
makeglossaries doc
lualatex doc.tex
Ora il CI non sa se il documento richiede o meno questo passaggio, ma dovrebbe comunque essere in grado di creare il documento. Nella documentazione dei glossari è menzionato il automake
parametro e l' --shell-escape
opzione per la compilazione di documenti che presumevo mi avrebbe permesso di compilare tutto in una volta ma questo non funziona con il CI. Allo stesso modo ho gli stessi problemi con ToC, indici, bibliografia ecc.
Sommario
Esiste un modo comune per automatizzare la compilazione complessa per diversi pacchetti? (O integrato in LuaLaTeX o alcuni script generici personalizzati)
C'è un problema con la mia configurazione che potrebbe impedire che tutti i passaggi avvengano automaticamente?
Ho guadato molte risorse per pacchetti specifici o LaTeX in generale, ma non sono riuscito a trovare qualcosa che funzioni. Il tuo aiuto è molto apprezzato.
Risposte
Come altri e te stesso hanno già detto, latexmksembra lo strumento corretto per questo lavoro. Per vedere come può essere implementato, lasciatemi evidenziare i bit rilevanti dalla mia pipeline CI di documento / modello LaTeX (su GitLab). Questo dovrebbe essere un esempio utilizzabile per una "compilazione complessa per diversi pacchetti". Entrerò anche nell'accompagnamento Dockerfilee nella configurazione CI di GitLab , oltre alla parte specifica di LaTeX latexmk
, perché tutte le parti sono strettamente accoppiate.
Tutto quanto descritto di seguito può essere visto implementato e (si spera ...) funzionante in questo progetto . Sto cercando di mantenere questa risposta il più autonoma possibile. Il collegamento al progetto conterrà lo stato più recente, che alla fine sostituirà questa risposta.
Pacchetti LaTeX e distribuzione (Debian)
Nella pipeline collegata, ci sono un paio di pacchetti che richiedono un'attenzione speciale nella configurazione. È improbabile che tu abbia gli stessi identici requisiti, ma li elencherò qui per completezza.
glossaries-extra, basato su
glossaries
, richiede la bib2glsconversione e l'elaborazione dei*.bib
file perlualatex
lavorare con.Ciò si riflette nella configurazione duplice:
- L'immagine Docker richiede un Java Runtime Environment per
bib2gls
, latexmk
deve essere informato della presenza dibib2gls
file.
- L'immagine Docker richiede un Java Runtime Environment per
pgfplotscon la sua
contour
opzione di\addplot3
( esempi ) richiede il gnuplotprogramma esterno . Di nuovo, questo si riflette in due modi:lualatex
(o il motore di tua scelta) richiede l'accesso in scrittura esterno pergnuplot
scrivere i risultati del suo calcolo su file perpgfplots
leggerli:--shell-escape
è necessario, di cuilatexmk
bisogna parlare.gnuplot
, poiché deve essere presente un pacchetto di distribuzione (al contrario di un pacchetto LaTeX), ad esempioapt-get install gnuplot
su un host Debian.
LaTeX non può incorporare
*.svg
file in modo nativo . L'incorporamento di tali file richiede prima la conversione in PDF (o un altro formato incorporabile). Ciò può essere ottenuto utilizzando Inkscape e la sua *.pdf_texroutine . Tuttavia, questo ci lascia con due file extra per file SVG:*.pdf
e*.pdf_tex
. Ad ogni modifica nel file SVG, i file derivati devono essere aggiornati. Questo porta a potenziali conflitti, anche nell'ambito del controllo delle versioni (git
ecc.): Quali versioni si vogliono mantenere?Il svgpacchetto LaTeX risolve questi problemi automatizzando il processo di conversione. I file generati
*.pdf
e*.pdf_tex
possono essere trattati come file temporanei / derivati e scartati liberamente. Rimangono solo gli SVG, come un'unica fonte di verità . Come bonus, essendo basati su testo (XML) , sono adatti anche per VCSgit
(che in realtà i PDF binari non sono).Come prima, questo si riflette nella configurazione seguente in due punti:
- Per chiamare la CLI
inkscape
(al contrario della GUI; affinché funzioni,inkscape
deve essere sul tuo$PATH
) per la lettura e la scrittura, il motore LaTeX richiede--shell-escape
. inkscape
deve essere disponibile nell'ambiente di compilazione (immagine Docker).
- Per chiamare la CLI
Utilizzando tcolorboxe il suo
\newtcolorbox
comando, ho creato un nuovo ambiente per gli esempi :\newtcolorbox[% auto counter,% number within=chapter,% % Set cleveref, see https://tex.stackexchange.com/a/126023/120853: crefname={Example}{Examples}, % List of Examples. *.loe file ending could clash with package thmtools, % careful if that is used! list inside=loe, ]{example}% Name of environment itself [2]% Number of arguments for the environment []% Default of optional argument, which is the first one. Use it for label {% beforeafter skip=18pt plus 4pt minus 4pt,% width=0.95\linewidth,% % Center box; see https://tex.stackexchange.com/a/273111/120853: enlarge left by=0.025\linewidth, title=Example\ \thetcbcounter: #2,% fonttitle=\sffamily,% leftrule=1mm,% arc is angular,% parbox,% Allows regular paragraph breaks breakable,% Breaks across pages enhanced,% Hands drawing to tikz rightrule=0mm,% bottomrule=0mm,% % Setting what ends up in 'list of' so that '<Title>' is not shown: list text=#2, #1,% colback=black!05,% colframe=black!70,% % float, }%
Questo sembra:
Ciò è rilevante perché si integra con l' komascriptutilizzo
list inside=loe
dell'istruzione, permettendoci di recuperare e stampare un elenco di esempi , come l' elenco standard di figure :% Declare a new list of contents, with the file suffix in brackets. % This will give access to \listof<name>s \DeclareNewTOC[% type=example,% This also creates types=example+s, that is by appending an s % Listname is "List of <Type>s" by default % listname={...}, ]{loe}
Infine,
latexmk
deve essere informato di questo*.loe
file appena creato . Questo è importante perchélatexmk
funziona esaminando i file ausiliari per le modifiche per valutare l'avanzamento e la fine della compilazione.In modo simile al punto precedente, l'utilizzo del listingspacchetto ci consentirà di stampare un elenco di elenchi dal
*.lol
file generato . Come prima,latexmk
vorrà saperlo.
Infine, questo culmina nel seguente .latexmkrc
file:
# Contents of .latexmkrc
# PERL latexmk config file
# PDF-generating modes are:
# 1: pdflatex, as specified by $pdflatex variable (still largely in use)
# 2: postscript conversion, as specified by the $ps2pdf variable (useless) # 3: dvi conversion, as specified by the $dvipdf variable (useless)
# 4: lualatex, as specified by the $lualatex variable (best) # 5: xelatex, as specified by the $xelatex variable (second best)
$pdf_mode = 4; # --shell-escape option (execution of code outside of latex) is required for the #'svg' package. # It converts raw SVG files to the PDF+PDF_TEX combo using InkScape. $lualatex = "lualatex --shell-escape";
# option 2 is same as 1 (run biber when necessary), but also deletes the
# regeneratable bbl-file in a clenaup (`latexmk -c`). Do not use if original
# bib file is not available!
$bibtex_use = 2; # default: 1 # Let latexmk know about generated files, so they can be used to detect if a # rerun is required, or be deleted in a cleanup. # loe: List of Examples (KOMAScript) # lol: List of Listings (listings package) push @generated_exts, 'loe', 'lol'; # Also delete the *.glstex files from package glossaries-extra. Problem is, # that that package generates files of the form "basename-digit.glstex" if # multiple glossaries are present. Latexmk looks for "basename.glstex" and so # does not find those. For that purpose, use wildcard. # Also delete files generated by gnuplot/pgfplots contour plots # (.dat, .script, .table), # and XML file generated by biber runs. $clean_ext = "%R-*.glstex %R_contourtmp*.* %R.run.xml";
# Grabbed from latexmk CTAN distribution:
# Implementing glossary with bib2gls and glossaries-extra, with the
# log file (.glg) analyzed to get dependence on a .bib file.
# !!! ONLY WORKS WITH VERSION 4.54 or higher of latexmk
# Push new file endings into list holding those files
# that are kept and later used again (like idx, bbl, ...):
push @generated_exts, 'glstex', 'glg';
# Add custom dependency.
# latexmk checks whether a file with ending as given in the 2nd
# argument exists ('toextension'). If yes, check if file with
# ending as in first argument ('fromextension') exists. If yes,
# run subroutine as given in fourth argument.
# Third argument is whether file MUST exist. If 0, no action taken.
add_cus_dep('aux', 'glstex', 0, 'run_bib2gls');
# PERL subroutine. $_[0] is the argument (filename in this case). # File from author from here: https://tex.stackexchange.com/a/401979/120853 sub run_bib2gls { if ( $silent ) {
# my $ret = system "bib2gls --silent --group '$_[0]'"; # Original version
my $ret = system "bib2gls --silent --group $_[0]"; # Runs in PowerShell
} else {
# my $ret = system "bib2gls --group '$_[0]'"; # Original version
my $ret = system "bib2gls --group $_[0]"; # Runs in PowerShell
};
my ($base, $path) = fileparse( $_[0] ); if ($path && -e "$base.glstex") { rename "$base.glstex", "$path$base.glstex";
}
# Analyze log file.
local *LOG;
$LOG = "$_[0].glg";
if (!$ret && -e $LOG) {
open LOG, "<$LOG"; while (<LOG>) { if (/^Reading (.*\.bib)\s$/) {
rdb_ensure_file( $rule, $1 );
}
}
close LOG;
}
return $ret;
}
latexmk
prenderà questo file e trarrà automaticamente le configurazioni da esso, se è denominato .latexmkrc
. Quindi la necessità di specificare la posizione di quel file svanisce esplicitamente se è presente in pwd
.
Build Environment (immagine Docker)
L'immagine Docker richiesta è più facilmente ottenibile utilizzando debian
un'immagine di base e l'installazione texlive-full
(e qualsiasi pacchetto richiesto menzionato sopra, o qualsiasi cosa tu abbia bisogno). Questo può essere semplice come il seguente Dockerfile
:
FROM debian:testing
RUN apt-get update --yes \
&& apt-get install --yes --no-install-recommends \
texlive-full
Per le mie esigenze, ho preparato un Dockerfile molto più coinvolto (commenti rimossi a causa del limite di caratteri):
ARG BASE_OS
ARG OS_VERSION
FROM ${BASE_OS}:${OS_VERSION} as BASE RUN apt-get update && \ apt-get install --yes --no-install-recommends \ wget \ ca-certificates \ perl FROM BASE as PREPARE ARG TL_VERSION ARG TL_INSTALL_ARCHIVE="install-tl-unx.tar.gz" ARG EISVOGEL_ARCHIVE="Eisvogel.tar.gz" ARG INSTALL_TL_DIR="install-tl" COPY texlive.sh . RUN \ ./texlive.sh get ${TL_VERSION} && \
wget https://github.com/Wandmalfarbe/pandoc-latex-template/releases/latest/download/${EISVOGEL_ARCHIVE} RUN \ mkdir ${INSTALL_TL_DIR} && \
tar --extract --file=${TL_INSTALL_ARCHIVE} --directory=${INSTALL_TL_DIR} --strip-components 1 && \
\
tar --extract --file=${EISVOGEL_ARCHIVE} FROM BASE as MAIN ARG BUILD_DATE="n/a" ARG VCS_REF="n/a" ARG TL_VERSION ARG TL_PROFILE="texlive.profile" LABEL \ maintainer="Alex Povel <[email protected]>" \ org.label-schema.build-date=${BUILD_DATE} \
org.label-schema.description="TeXLive with most packages, JavaRE, Inkscape, pandoc and more" \
org.label-schema.url="https://collaborating.tuhh.de/alex/latex-git-cookbook" \
org.label-schema.vcs-url="https://github.com/alexpovel/latex-extras-docker" \
org.label-schema.vcs-ref=${VCS_REF} \ org.label-schema.schema-version="1.0" ARG INSTALL_DIR="/install/" WORKDIR ${INSTALL_DIR}
COPY ${TL_PROFILE} . COPY --from=PREPARE /install-tl/ /texlive.sh ./ COPY --from=PREPARE /eisvogel.tex /usr/share/pandoc/data/templates/eisvogel.latex ARG TEXLIVE_INSTALL_PREFIX="/usr/local/texlive" ARG TEXLIVE_INSTALL_TEXDIR="${TEXLIVE_INSTALL_PREFIX}/${TL_VERSION}" ARG TEXLIVE_INSTALL_TEXMFCONFIG="~/.texlive${TL_VERSION}/texmf-config"
ARG TEXLIVE_INSTALL_TEXMFVAR="~/.texlive${TL_VERSION}/texmf-var" ARG TEXLIVE_INSTALL_TEXMFHOME="~/texmf" ARG TEXLIVE_INSTALL_TEXMFLOCAL="${TEXLIVE_INSTALL_PREFIX}/texmf-local"
ARG TEXLIVE_INSTALL_TEXMFSYSCONFIG="${TEXLIVE_INSTALL_TEXDIR}/texmf-config" ARG TEXLIVE_INSTALL_TEXMFSYSVAR="${TEXLIVE_INSTALL_TEXDIR}/texmf-var"
RUN ./texlive.sh install ${TL_VERSION} RUN luaotfload-tool --update || echo "luaotfload-tool not found, skipping." RUN apt-get update && \ apt-get install --yes --no-install-recommends \ default-jre-headless \ inkscape \ gnuplot-nox \ ghostscript RUN apt-get update && \ apt-get install --yes --no-install-recommends \ librsvg2-bin \ pandoc WORKDIR /tex/ RUN rm --recursive ${INSTALL_DIR}
CMD [ "--lualatex" ]
ENTRYPOINT [ "latexmk" ]
Permette all'utente di specificare quale versione TeXLive (attingendo dai propri archivi) e Debian costruire. Per questo, richiede il seguente texlive.sh
script. Sceglie tra il latest
tag (Docker) e alcune versioni storiche (ad esempio Debian 9, TeXLive 2018), nel qual caso viene scaricato dagli archivi TUG :
#!/bin/bash
# Script to fetch `install-tl` script from different sources, depending on argument
# given.
# Error out of any of the variables used here are unbound, e.g. no CLI arg given.
set -u
usage() {
echo "Usage: $0 get|install latest|version (YYYY)" } if [[ $# != 2 ]]; then
echoerr "Unsuitable number of arguments given."
usage
# From /usr/include/sysexits.h
exit 64
fi
# From: https://stackoverflow.com/a/2990533/11477374
echoerr() { echo "$@" 1>&2; } # Bind CLI arguments to explicit names: ACTION=${1}
VERSION=${2} # Download the `install-tl` script from the `tlnet-final` subdirectory, NOT # from the parent directory. The latter contains an outdated, non-final `install-tl` # script, causing this exact problem: # https://tug.org/pipermail/tex-live/2017-June/040376.html HISTORIC_URL="ftp://tug.org/historic/systems/texlive/${VERSION}/tlnet-final"
REGULAR_URL="http://mirror.ctan.org/systems/texlive/tlnet"
case ${ACTION} in "get") if [[ ${VERSION} == "latest" ]]
then
# Get from default, current repository
wget ${REGULAR_URL}/${TL_INSTALL_ARCHIVE}
else
# Get from historic repository
wget ${HISTORIC_URL}/${TL_INSTALL_ARCHIVE}
fi
;;
"install")
if [[ ${VERSION} == "latest" ]] then # Install using default, current repository perl install-tl \ --profile=${TL_PROFILE}
else
# Install using historic repository (`install-tl` script and repository
# versions need to match)
perl install-tl \
--profile=${TL_PROFILE} \ --repository=${HISTORIC_URL}
fi
# For `command` usage, see:
# https://www.gnu.org/software/bash/manual/html_node/Bash-Builtins.html#Bash-Builtins.
# The following test assumes the most basic program, `tex`, is present.
if command -v tex &> /dev/null
then
# If automatic `install-tl` process has already adjusted PATH, we are happy.
echo "PATH and installation seem OK."
else
# Try and make installation available on path manually.
#
# The first wildcard expands to the architecture (should be 'x86_64-linux',
# which might change in TeXLive upstream, so do not hardcode here),
# the second one expands to all binaries found in that directory.
# Only link if directory exists, else we end up with a junk symlink.
EXPECTED_INSTALL_TEXDIR=${TEXLIVE_INSTALL_TEXDIR}/bin/* # `ls` found to be more robust than `[ -d ... ]`. if ls ${EXPECTED_INSTALL_TEXDIR} 1>/dev/null 2>&1
then
SYMLINK_DESTINATION="/usr/local/bin"
# "String contains", see: https://stackoverflow.com/a/229606/11477374
if [[ ! ${PATH} == *${SYMLINK_DESTINATION}* ]]
then
# Should never get here, but make sure.
echoerr "Symlink destination ${SYMLINK_DESTINATION} not in PATH (${PATH}), exiting."
exit 1
fi
echo "Symlinking TeXLive binaries in ${EXPECTED_INSTALL_TEXDIR}" echo "to a directory (${SYMLINK_DESTINATION}) found on PATH (${PATH})" # Notice the wildcard: ln --symbolic --verbose ${EXPECTED_INSTALL_TEXDIR}/* ${SYMLINK_DESTINATION}
if command -v tex &> /dev/null
then
echo "PATH and installation seem OK."
else
echoerr "Manual symlinking failed and TeXLive did not modify PATH automatically."
echoerr "Exiting."
exit 1
fi
else
echoerr "Expected TeXLive installation dir not found and TeXLive installation did not modify PATH automatically."
echoerr "Exiting."
exit 1
fi
fi
;;
*)
echoerr "Input not understood."
usage
# From /usr/include/sysexits.h
exit 64
esac
Inoltre, l'installazione di TeXLive viene eseguita manualmente utilizzando il loro install-tlscript. Per un'installazione automatica, richiede un file di profilo , come questo texlive.profile
(commenti rimossi a causa del limite di caratteri):
selected_scheme scheme-custom
collection-basic 1
collection-bibtexextra 1
collection-binextra 1
collection-fontsextra 1
collection-fontsrecommended 1
collection-fontutils 1
collection-formatsextra 1
collection-langenglish 1
collection-langeuropean 1
collection-langgerman 1
collection-latex 1
collection-latexextra 1
collection-latexrecommended 1
collection-luatex 1
collection-mathscience 1
collection-pictures 1
collection-plaingeneric 1
collection-publishers 1
collection-xetex 1
collection-context 0
collection-games 0
collection-humanities 0
collection-langarabic 0
collection-langchinese 0
collection-langcjk 0
collection-langcyrillic 0
collection-langczechslovak 0
collection-langfrench 0
collection-langgreek 0
collection-langitalian 0
collection-langjapanese 0
collection-langkorean 0
collection-langother 0
collection-langpolish 0
collection-langportuguese 0
collection-langspanish 0
collection-metapost 0
collection-music 0
collection-pstricks 0
collection-texworks 0
collection-wintools 0
instopt_adjustpath 1
instopt_adjustrepo 0
instopt_letter 0
instopt_portable 0
instopt_write18_restricted 1
tlpdbopt_autobackup 0
tlpdbopt_backupdir tlpkg/backups
tlpdbopt_create_formats 1
tlpdbopt_desktop_integration 0
tlpdbopt_file_assocs 0
tlpdbopt_generate_updmap 0
tlpdbopt_install_docfiles 0
tlpdbopt_install_srcfiles 0
tlpdbopt_post_code 1
Se lo fai, questo file è il cuore del processo di creazione dell'immagine. Specifica quali pacchetti LaTeX scaricare e installare. Puoi modificare, e probabilmente soprattutto snellire, la tua build qui. Ad esempio, l'installazione / il download di file di documentazione è esplicitamente omesso qui, cosa che non è possibile quando si esegue semplicemente apt-get install texlive-full
, risparmiando più GB di spazio.
Nota che queste immagini sono già compilate e disponibili (in modo costantemente integrato: ogni git push
sul repository di origine attiverà una build) su DockerHub . L'utilizzo di questi renderà la stessa immagine della creazione da soli, senza sovraccaricare i server di archivio TUG . Queste immagini vengono create automaticamente utilizzando il build hook di DockerHub , dove la pagina delle impostazioni ha un aspetto simile (vedi anche qui ):

Configurazione CI
Questo è specifico per GitLab. Non l'ho ancora implementato per GitHub / Travis.
In un dato repository con uno o più *.tex
file alla radice e a README.md
, la configurazione YAML CI di seguito (senza commenti a causa del limite di caratteri):
- Estrai l'immagine dal repository DockerHub sopra, sostituendo qualsiasi
ENTRYPOINT
istruzione con niente (ovvero una normale shell). Questo è importante affinché lascript
parte funzioni, mentre anENTRYPOINT
è conveniente per eseguire il contenitore sul desktop. - Sostituisci
n.a.
in\newcommand*{\GitVersion}{n.a.}
e\newcommand*{\GitShortHash}{n.a.}
dal*.cls
file di classe LaTeX (nella radice del progetto) con i valori attuali e correnti di quella build. Ciò consente di stampare i metadati VCS nel PDF. - Costruisci il LaTeX in PDF semplicemente emettendo
latexmk
. Trarrà le sue istruzioni da.latexmkrc
, vedi sopra. - Compilare un PDF da
README.md
, utilizzandopandoc
, che ancora una volta utilizzalualatex
per la conversione. Questo sta usando un modello per un output più carino. Questo passaggio è più un espediente / vetrina perpandoc
.
I PDF risultanti sono artefatti della pipeline CI e possono essere scaricati dopo un'esecuzione corretta.
default:
image:
name: alexpovel/latex
entrypoint: [ "" ]
retry:
max: 1
when: runner_system_failure
artifacts:
name: "$CI_COMMIT_REF_NAME"
paths:
- "*.pdf"
stages:
- prepare
- build
insert_git_metadata:
stage: prepare
script:
- |
declare -A GITINFO=(
[GitVersion]=$CI_COMMIT_REF_NAME [GitShortHash]=$CI_COMMIT_SHORT_SHA
)
- |
for k in "${!GITINFO[@]}" do sed -i "s~\(newcommand\*{\\\\$k}\){.*}~\1{${GITINFO[$k]}}~" *.cls
done
artifacts:
paths:
- "*.cls"
needs: []
build_latex:
stage: build
script:
- latexmk
dependencies:
- insert_git_metadata
build_pandoc:
stage: build
script:
- 'sed -i "s~\(^date: \)\".*\"~\1\"$(date +"%B %-d, %Y")\"~" README.md'
- |
pandoc README.md \
--template eisvogel --pdf-engine=lualatex --number-sections \
-o README.pdf
needs: []
Mi spiace, non so cosa significhi CI, ma se hai GNU make sulla tua macchina, potresti scrivere un piccolo makefile come questo:
FILE=yourfilename
.PHONY: clean cleanall
all:$(FILE).pdf clean: -rm *.aux *.blg *.out *.bbl *.lot *.lof *.glo *.ist *.acn *.acr *.alg *.glg *.gls *.toc *.bcf *.run.xml cleanall: -rm *.aux *.blg *.out *.bbl *.log *.lot *.lof *.glo *.ist *.acn *.acr *.alg *.glg *.gls *.toc *.bcf *.run.xml #report#.pdf $(FILE).pdf: *.tex
E:\miktex-portable\texmfs\install\miktex\bin\x64\lualatex.exe $(FILE) E:\miktex-portable\texmfs\install\miktex\bin\x64\biber.exe $(FILE)
E:\miktex-portable\texmfs\install\miktex\bin\x64\makeglossaries.exe $(FILE) E:\miktex-portable\texmfs\install\miktex\bin\x64\lualatex.exe $(FILE)
E:\miktex-portable\texmfs\install\miktex\bin\x64\lualatex.exe $(FILE)
L'esempio è fatto per Windows come sistema operativo. Invece di E: \ miktex-portable ... \ adatta il percorso che si adatta alla tua installazione. Se hai GNU / Linux puoi impostare $ PATH in modo tale da non dover specificare il percorso completo degli eseguibili (es. Basta dire 'lualatex $ (FILE)' ecc.). Resta inteso che l'elenco di referenze viene creato utilizzando biber e biblatex. Il makefile (stesso nome file) dovrebbe essere posizionato nella stessa directory in cui si trovano i file * .tex. Quindi, devi solo inserire "make" nel terminale della riga di comando. Allo stesso modo 'make clean' e 'make cleanall' possono aiutarti a riordinare la tua directory.
Quello che ho finito per fare è stato applicare latexmk
all'elemento della configurazione e applicare regole aggiuntive latexmk
per aiutare con il glossaries
pacchetto.
La build automatizzata esegue le seguenti operazioni dopo aver configurato l'ambiente di compilazione e l'immagine docker miktex:
mpm --install=latexmk
Durante la creazione del documento, viene utilizzato il seguente comando:
latexmk -r "<path-to-rc-file>/.latexmkrc" -lualatex -latexoption="-interaction=nonstopmode"
Il .latexmkrc
file si trova in un sottomodulo Git condiviso tra tutti i nostri repository di documenti dove abbiamo anche le nostre classi di documenti condivise, ecc.
Ecco i contenuti di .latexmkrc
# This shows how to use lualatex (http://en.wikipedia.org/wiki/LuaTeX)
# with latexmk.
#
# WARNING: The method shown here is suitable only for ver. 4.51 and
# later of latexmk, not for earlier versions.
#
$pdf_mode = 4; $postscript_mode = $dvi_mode = 0; # This shows how to use the glossaries package # (http://www.ctan.org/pkg/glossaries) and the glossaries-extra package # (http://www.ctan.org/pkg/glossaries-extra) with latexmk. add_cus_dep( 'acn', 'acr', 0, 'makeglossaries' ); add_cus_dep( 'glo', 'gls', 0, 'makeglossaries' ); $clean_ext .= " acr acn alg glo gls glg";
sub makeglossaries {
my ($base_name, $path) = fileparse( $_[0] ); pushd $path;
my $return = system "makeglossaries", $base_name;
popd;
return $return;
}
preso da qui .
Il risultato finale garantisce un'esperienza di compilazione coerente indipendentemente dal documento e dal suo contenuto. Questo approccio è anche flessibile ed estensibile e può consentire di utilizzare la stessa identica catena di strumenti da un contenitore docker locale durante la scrittura.