Skip to content

Conversation

@kprussing
Copy link
Contributor

The BibTeX and Biber actions when processing LaTeX files were stripping multiple extensions before passing the file to either bibtex or biber. This would result in the bibliography tool not finding the correct .aux file and running LaTeX multiple times for no gain.

Example

Given a main LaTeX file named main.extra.tex.

Old behavior:

  1. latex main.extra produces the file main.extra.aux
  2. bibtex main call issued by LaTeX Builder
  3. BibTeX issues warning No file main.extra.aux
  4. LaTeX reruns maximum number of times and does not typeset the bibliography

Expected behavior:

  1. latex main.extra produces the file main.extra.aux
  2. bibtex main.extra call issued by LaTeX Builder
  3. BibTeX succeeds and processing finishes

Gist demonstrating the behavior

Contributor Checklist:

  • I have created a new test or updated the unit tests to cover the new/changed functionality.
  • I have updated CHANGES.txt and RELEASE.txt (and read the README.rst).
  • I have updated the appropriate documentation

This test (should) generate two identical LaTeX input files: main.tex
and main.extra.tex.  The should compile to the same content, but SCons
strips accidentally strips the '.extra' from the second preventing it
from finding the bibliography file.  The test needs to be checked on a
non-Windows system because Miktek does not support the ~ in the
shortened path name to the temp directory.
The second argument to the action should be the aux file not the
bibliography file.  Also, we have to add the bib extension to the target
because it will be stripped by the command string via TARGET.filebase.
The normalized text in the PDF should be the same.  That ensures we have
the proper output from the stripping.
Testing on non-Windows finds pdflatex on the PATH so pulling in the
os.envrion is not necessary.
@bdbaddog bdbaddog changed the title Bibtex striping extra extensions Bibtex stripping extra extensions Nov 20, 2025
@bdbaddog
Copy link
Contributor

And this works if the file is named main_extra.tex right?

(I updated your test to use our new standard test header (you can see it in template/test.py)

@kprussing
Copy link
Contributor Author

It does. The underscore isn't stripped by the .splitext in the original. It only happened when more that one . was in the file name (functionally, splitext is called multiple times instead of once).

(I saw the change. I was just lazy and copied one of the other TEX tests and made the logic fit. Now I know to look at the template for next time)

…xtra-extensions

Also resolved ordering of additions to CHANGES.txt
@mwichmann mwichmann added the LaTex LaTex related issues. label Nov 21, 2025

test.write(["SConstruct"], f"""\
import os
env = Environment(tools=['pdftex', 'tex'])
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

though it has nothing to do with correctness, we often sneak in a line before the initial env creation like

DefaultEnvironment(tools=[])

This is purely a hack for performance running the testsuite, and isn't something people should actually have to do. No downvote if not changed.

@mwichmann mwichmann moved this to In review in Next Release Nov 23, 2025
@bdbaddog
Copy link
Contributor

bdbaddog commented Nov 27, 2025

This is not really a latex/bibtex issue at it's root, it's really about how SCons.Util.splitext treats a filename with two (or more) .'s in it.
Which honestly has been a long term issue, and there have been many point fixes (like this one).
Well combined with adding the builder suffix to a file which already apparently (though not in reality) has explicitly specified a suffix..

(this is the root of my delay in merging this PR BTW. I wanted to think a bit about this, and if perhaps we could resolve this by improving the SCons.Util.splitext logic instead. so please bear with me)

@kprussing
Copy link
Contributor Author

No worries. It's your project and I'm just a visitor!

From what I can tell, Scons.Util.splitext behaves just like os.splitext and only splits off the last extension. The problem here was it (effectively) being called twice on the same file name (I don't know how TARGET.filebase is implemented under the hood).

The alternate explanation here was the wrong target and source were being passed to the Action. That situation would need to be point resolve no matter what.

@mwichmann
Copy link
Collaborator

Don't see how improving splitext helps the problem of being called twice, each time one chunk is hacked off?

@mwichmann
Copy link
Collaborator

From what I can tell, Scons.Util.splitext behaves just like os.splitext and only splits off the last extension.

It does a little less work is all to be just slightly faster... mainly, it doesn't account for bytes vs strings or for pathlib objects - the scons one just assumes always a plain string.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

LaTex LaTex related issues.

Projects

Status: In review

Development

Successfully merging this pull request may close these issues.

3 participants