Methods for debugging package conflicts
... that don't make me want to pull my (remaining) hair out.
I'm preparing a long journal article with a wide array of necessary
packages and a publisher-specific class file.
In this specific case, I've recently added
\usepackage{algorithm}
\usepackage[noend]{algpseudocode}
When building the TeX file I'm now encountering a typical conflict error:
("C:\Program Files\MiKTeX 2.9\tex\latex\algorithms\algorithm.sty"
Package: algorithm 2009/08/24 v0.1 Document Style `algorithm' - floating
environment
! LaTeX Error: Command \c@algorithm already defined.
Or name \end... illegal, see p.192 of the manual.
See the LaTeX manual or LaTeX Companion for explanation.
Type H <return> for immediate help.
...
l.96 \floatname
{algorithm}{\ALG@name}
Your command was ignored.
Type I <command> <return> to replace it with another command,
or <return> to continue without it.
The resulting PDF looks fine, including the new algorithms, but since I'm
collaborating on the source with other parties—and since I'm the kind of
person who has nightmares about unbalanced parentheses—I don't want to
commit changes that introduce error messages.
Aside from this specific case (which I assume is quite specialised, but
which serves as a useful example), I'm wondering if there's any methods or
helpful tips to debug conflicts like this? I have tried commenting out
various packages to do a "binary search" on the problematic package, but
then I encounter other errors or the build fails due to the necessary
packages being omitted. I have tried building up the packages from an MWE
but it is time consuming given the complexity of the document and not
(yet) yielding any insights.
This leads me to wonder if there's a better way ... how would a TeX expert
approach the problem?
For example, is there any hints to be had from the pdfTex .log file as to
where \c@algorithm is already defined? Is there another method to trace
where the definition is? Maybe the definition can be renamed before
including the algorithm package? Maybe there's any resource online that
offers a matrix of typical package conflicts? Or maybe there's some other
general method to identify and resolve such conflicts?
(Of course, there's a bunch of incompatibility questions already on this
site, but I could not find any that address generic methods on how to
identify conflicts/incompatibilities.)
No comments:
Post a Comment