# Package parameters should depend on the build environment

I'm working on the same TeX file (it's in a git repository) at different places. However, these different places have different versions of LaTeX installed.

At work, I need these headers:

\usepackage[caption=false]{caption}
\usepackage[font=footnotesize]{subfig}


At home (newer version of the subfig package), I need these headers:

\usepackage[font=footnotesize,caption=false]{subfig}


The wrong headers will cause the compile to fail: Using the "work" headers at home, subfig complains that I should stop using the caption package. Using the "home" headers at work, subfig complains about unknown parameters.

Is there a way to have LaTeX detect the version of subfig available and use the "correct" \usepackage statements?

-
I suppose telling your work sysadmins to update their version of subfig is out of the question? – Seamus Nov 29 '10 at 16:04
Or installing the updated subfig in a texmf directory within your home directory at work? – Matthew Leingang Nov 29 '10 at 16:10
You might be able to change to the subcaption package that replaces the not longer maintained subfig package well. This might prevent the option clash. Otherwise you might be able to introduce a switch that you have to set depending on what system you work on. – Martin H Nov 29 '10 at 16:24
As it's in a git repository, why not simply have home and work branches that differ only by the options to the packages? – Loop Space Nov 29 '10 at 19:48
@Seamus, @Matthew: Yes, that's my backup plan, but I was wondering if it was possible to make a TeX-based solution that "just works" independent of the system. – Heinzi Dec 5 '10 at 14:49

You could use an external file:

\usepackage[caption=false]{caption}
\usepackage[font=footnotesize]{subfig}


% foo, see question


main.tex:

\documentclass{foo}

\usepackage{bar}

%...
begin{document}
%...


Then you can write a small makefile or shell-script that creates the right header.tex link depending on your environment, e.g. a build.sh:

#!/bin/sh
if [ hostname = "foo"]
then
fi

pdflatex main.tex

-
I like the idea with the header. I'd just call both files (at home and at work) header.tex, of course with different contents. – Hendrik Vogt Nov 29 '10 at 17:57
@Hendrik: I see your point, but that would mean that my ability to compile depends on a file that's not in the VCS... I'm not sure I like that. – Heinzi Dec 5 '10 at 14:54
That sounds like a nice idea. Is there any chance to make this kind of check inside of TeX rather than requiring an external shell script? – Heinzi Dec 5 '10 at 14:55
@Heinzi: I don't know how to call external programs from tex code. It seems to be possible because e.g. you can instruct pgfplots to automatically call gnuplot for certain features. If it is convenient is another question. – maxschlepzig Jan 19 '11 at 21:34

You could try

\IfFileExists{caption3.sty}{
% actual syntax to load the subfig package without the caption package
\usepackage[font=footnotesize,caption=false]{subfig}
}{
% abbandoned syntax to load the subfig package without the caption package
\usepackage[caption=false]{caption}
\usepackage[font=footnotesize]{subfig}
}

It's not bullet-proof, but should hopefully work for most TeX systems.

-

This is getting a bit involved for the comments, but it's a continuation of what I said in the comments to the question, namely that this sort of thing is precisely what the version control system is designed to solve. I use bzr, not git, but they are both distributed version control systems so I'm pretty sure that this will work in git as well, but the commands will be called something different.

First, set up a main repository and put something there:

mkdir bzr_test        # create the directory
cd bzr_test           # go into it
bzr init-repo .       # initialise the repository
bzr init main         # create the main tree for the project
cd main               # go into it
vi document.tex       # create the first document


\documentclass{article}

\usepackage{subfig}

\begin{document}
Hello World
\end{document}


Now we commit that document and create two branches:

bzr add document.tex             # Tell bzr to notice this document
bzr commit -m 'Main document'    # Commit the changes
cd ..                            # Back to containing directory
bzr branch main work             # Create a work branch
bzr branch main home             # And a home one


In each branch, we modify the document as required:

At work:

\documentclass{article}

\usepackage[caption=false]{caption}
\usepackage[font=footnotesize]{subfig}

\begin{document}
Hello World
\end{document}


At home:

\documentclass{article}

\usepackage[font=footnotesize,caption=false]{subfig}

\begin{document}
Hello World
\end{document}


And we commit those changes (and we ensure that these are the only changes at this stage).

cd work                             # Not sure which directory we're in!
bzr commit -m 'Headers for work'    # Commit changes for work
cd ../home                          # Go to home
bzr commit -m 'Headers for home'    # Commit changes for home


Now we do some revision on one of the branches.

cd ../work
vi document.tex
bzr commit -m 'Major revisions'


Suppose that in work we now have:

\documentclass{article}

\usepackage[caption=false]{caption}
\usepackage[font=footnotesize]{subfig}

\begin{document}
Hello World

Greetings Earthlings
\end{document}


Now we want to carry those over to the home branch. The key here is to do a selective merge. If we just did a basic merge then it would merge everything from the common parent up to the current revision. However, we want to ignore the first revision.

cd ../home
bzr merge ../work -r2..


And now we see that we have:

\documentclass{article}

\usepackage[font=footnotesize,caption=false]{subfig}

\begin{document}
Hello World

Greetings Earthlings
\end{document}


The only annoying thing about this is that you have to remember which revision you merged from each time so that you can merge from just that revision to the end. I suspect that there are better ways to manage this, but I'm not an expert on version control systems and am offering this as more proof-of-concept than the ideal solution. My basic point is that tracking changes like this is exactly what version control is designed for, so let it do its job and let TeX do its job.

-
Wow, nice answer, thanks! – Heinzi Dec 7 '10 at 8:11