Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WIP] Bugfix/managan/latex scanner #3854

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

managan
Copy link
Contributor

@managan managan commented Jan 4, 2021

This pull request aims to fix a case where the LatexScanner fails.

The example test is when the source includes \input{filename} and the file filename is not present. This file does not show up in --tree=all output and then we get an error from pdflatex when it can not find the file.

The scanner needs to be updated to report the file is in the source tree even when it is not present.

The source change avoids an exception being thrown when the builder tries to determine if the deck is a tex file or a latex file.

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 read the README.rst)
  • I have updated the appropriate documentation

This currently fails regardless.
The Latex scanner need fixing to report that a required
file that is input was not found
@mwichmann mwichmann added the LaTex LaTex related issues. label Jan 4, 2021
@managan
Copy link
Contributor Author

managan commented Jan 4, 2021

This is tied to Fixes #2972

@bdbaddog
Copy link
Contributor

bdbaddog commented Mar 8, 2021

@managan - Is this ready to go? Or still have some items outstanding?

@bdbaddog
Copy link
Contributor

@managan - just a ping to see if you're still working on this?

@managan
Copy link
Contributor Author

managan commented Jul 12, 2021 via email

@bdbaddog
Copy link
Contributor

Hi, Still trying to free up some time for this. We are now in GA but still doing things on the new house!

No worries. Just wanted to touch base.

Enjoy the house process. ;)

@bdbaddog
Copy link
Contributor

@managan - just a ping to see if you have time to complete this PR.

@managan
Copy link
Contributor Author

managan commented Sep 11, 2023

I am retiring at the end of November. I am putting this on my list of things to look at in December!

@bdbaddog
Copy link
Contributor

I am retiring at the end of November. I am putting this on my list of things to look at in December!

Congratulations!
And thank you! :)

@managan
Copy link
Contributor Author

managan commented Sep 11, 2023 via email

@mwichmann
Copy link
Collaborator

mwichmann commented Mar 15, 2024

Came across this again closing down old browser tabs ;-) This in concept is similar to some Fortran stuff I've been wrestling with. A lot of scanners work on the assumption that "if a scanned dependency is not found, don't add it to the dep list, and just move on, as if these were no problem" - you see the same pattern over and over, probably copied:

            node = node.rfile()
            if not node.exists():
                return []

As far as I've been able to deduce, the root of this assumption is that you don't want to generate dependencies for system headers - if /usr/include/stdio.h is missing, we don't have a way to regenerate it, so there's no point in adding it as a dep, the build will fail anyway when the header isn't found by the compiler, and the user has to install something through their package manager to resolve it. But we don't have any special way of determining that something is a system-provided file as opposed to a project-provided one. Thus - we just ignore the case of not finding a file that looks like it's required. This sort of works for C projects, actually.

The problem is, if the file could be generated, then we absolutely want a dependency on it, so SCons can force it to be built - normally before the thing that includes it, or we get build-ordering problems that manifest as missing files - there are a number of these in the issue tracker (Fortran, Java, SWIG, D off the top of my head).

Don't have a general answer for this class of problems, because we don't have enough information to make an accurate decision. In the Fortran case, it manifests with module files, so I'm trying to treat a module dependency separately and not apply the template above. That's not necessarily pretty... Can we do something similar with latex? Is this in fact a case of the same problem?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
LaTex LaTex related issues.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

TEX builder/logic: A missing file causes failure with poor error message
3 participants