In a large project, it is not uncommon to have LaTeX documents built in
different subdirectories and to have each subdirectory include
UseLATEX.cmake. However, loading UseLATEX.cmake multiple times caused
the pdf, dvi, etc. targets to be created multiple times even though the
intention is to have them loaded once. This change creates each target
only once.
Previously, the EXCLUDE_FROM_ALL option broke both the dependency from
the all target and the dependency from the dvi, pdf, etc. targets. However,
there is plenty of reason to want only one or the other, so the
EXCLUDE_FROM_ALL option was broken up into a second EXCLUDE_FROM_DEFAULTS
that controls the second set of dependencies.
Removed the DEFAULT_* arguments. Instead, have a CMake variable named
LATEX_DEFAULT_BUILD that specifies what the default build should be.
This CMake variable is initialized with an environment variable of the
same name or PDF if none is specified. This allows each user to specify
a default build without having to change the configuration.
There is also an EXCLUDE_FROM_ALL option that, like the same option in
add_executable, keeps the document from being built in the default all
target.
UseLATEX.cmake finds several executables for compiling documents and
converting files. Previously these were not marked as advanced, but
CMake now conventionally makes them advanced to avoid cluttering the
GUI.
Change "set (" to "set("
Change some set commands that were actually appending a list to a list(append
command, which shows better the point of the command and could be faster.
That module is actually based off the code that originally came from
UseLATEX.cmake, but now that it exists and is supported by the CMake
community, there is no reason to have a second copy here.
The arguments for else and endif commands are now no longer necessary. In
fact, the are no longer encouraged. This is because, in addition to it
being annoying to exactly match expressions, it becomes confusing when
there is an else clause. (The expression is actually the inverse of the
case for the else clause.)
Older versions of Windows use the path C:\Windows\system32. Newer ones
use the path C:\Windows\System32 (with a capitol S). They are somewhat
equivalent because Windows file system is not case sensitive, but it
made the check for the system32 directory fail. This change first converts
the path the lowercase to do a non case sensitive comparison.
Previously, a simple string compare was performed. However, if the
user enters a relative string to LATEX_OUTPUT_PATH ("." would be
expected), then the string compare to the absolute path in
CMAKE_CURRENT_SOURCE_DIR would fail even though the two paths point
to the same place.
Fix the problem by first converting LATEX_OUTPUT_PATH to an absolute
path.
A recent change from macros to functions changed the scoping rules
that caused the variable that held the raster scale to not be defined
where the build targets were generated (and thus scaling did not occur).
Previously, all image files were classified into groups of files supported
by latex and those supported by pdflatex. This change also defines files
that are not directly supported by either (and therefore always have to
be converted).
Also added svg, tiff, and gif files to the list of those supported.
Some distributions of LaTeX simply do not handle image files with multiple
periods properly (they cannot identify the extension/format correctly).
The warning suggests best practice of renaming files.
The behavior of GET_FILENAME_COMPONENTS with arguments NAME_WE and EXT
would identify the extension as everything after the *first* period.
This messes up the identification of file types, which pretty much
always have short extensions (like .tex, .bib, .eps, etc.).
Variables holding things like LATEX_ADD_DOCUMENT arguments have to cached
now that we are using functions instead of macros. They should be declared
internal since the user should neither see nor set them, but I had
misspelled INTERNAL.
This basically undo's commit acc72788dd.
Apparently, there IS harm in running bibtex on an aux file with no cites
in it. Bibtex will give you an error in this case. It is also unclear
whether it is even possible to use the standard cites when using bibtex
or if you ever want to. If you do, there is still the fallback of
adding the main target to the MULTIBIB_NEWCITES command, if you know
enough to do so.
Even when using multibib, it is possible to still use the main cite
commands that go to the main aux file. Might as well run bibtex there.
There should be no harm.
I was confused when this was presented to me. I thought it represented
multiple .bib files, which is not the case. It represents aux files
created with the \newcites command in the multibib package. I hope this
name will create less confusion.
When parsing arguments, there is an IF statement that compares an
argument to an argument name (such as BIBFILES, IMAGES, etc.).
If there exists a variable with the same name, then the IF statement
will also try to dereference the variable and compare them. Thus,
if that variable equaled one of the arguments, it would be incorrectly
identified as an argument name.
As an example, consider this CMake code.
set(BIBFILES mydoc.bib)
add_latex_document(mydoc.tex BIBFILES ${BIBFILES})
These arguments, obviously, expand to "mydoc.tex;BIBFILES;mydoc.bib".
When checking the argument mydoc.bib, you would expect it to be
considered an argument to BIBFILES. However, deep in the call stack
there is an if statement that expands to
IF (BIBFILES STREQUAL mydoc.bib)
Clearly we mean these to be unequal. But because BIBFILES is also
a variable containing mydoc.bib, CMake considers this to be true.
Thus, UseLATEX though mydoc.bib was the start of a list of bibliography
files rather than a bibliography file itself.
The problem is solved by prepending "non_a_var_" to each string we
are comparing.
IF (not_a_var_BIBFILES STREQUAL not_a_var_mydoc.bib)
This makes it highly unlikely that either side of this comparison
will be a variable that gets expanded.
Add all known auxiliary files that LaTeX generates to the clean target.
Also add the final generated files (dvi, ps, pdf). Also add these
files to the auxclean target, which differs from the regular clean
in that it does not clean things like images that take a while to
rebuild.
