[WIP] Bugfix/managan/latex scanner #3854
Conversation
fixing indentation
This currently fails regardless. The Latex scanner need fixing to report that a required file that is input was not found
|
This is tied to Fixes #2972 |
|
@managan - Is this ready to go? Or still have some items outstanding? |
|
@managan - just a ping to see if you're still working on this? |
|
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. ;) |
|
@managan - just a ping to see if you have time to complete this PR. |
|
I am retiring at the end of November. I am putting this on my list of things to look at in December! |
Congratulations! |
|
Turning 68 in a few weeks so it is time!!
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Rob Managan
WCI/DP Division LLNL
P.O. Box 808, L-170
Livermore, CA 94551-0808
Email: ***@***.***
Phone: 925-423-0903 FAX: 925-422-3389
Mobile: 925-341-9939
From: William Deegan ***@***.***>
Reply-To: SCons/scons ***@***.***>
Date: Monday, September 11, 2023 at 5:33 PM
To: SCons/scons ***@***.***>
Cc: Rob Managan ***@***.***>, Mention ***@***.***>
Subject: Re: [SCons/scons] [WIP] Bugfix/managan/latex scanner (#3854)
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! :)
—
Reply to this email directly, view it on GitHub<https://urldefense.us/v3/__https:/github.com/SCons/scons/pull/3854*issuecomment-1714615210__;Iw!!G2kpM7uM-TzIFchu!wGIeoHASPiUqDa7DMfLHyJlzecfwsv9IfpQVc7tn4iyPN_EbL4oeIApLEPGKy4kh5dZ_qzDOvkjLLfg_to8r2q4RcA$>, or unsubscribe<https://urldefense.us/v3/__https:/github.com/notifications/unsubscribe-auth/AAATRLWFVIOPPUBBGYB5ZEDXZ57THANCNFSM4VTYU2WA__;!!G2kpM7uM-TzIFchu!wGIeoHASPiUqDa7DMfLHyJlzecfwsv9IfpQVc7tn4iyPN_EbL4oeIApLEPGKy4kh5dZ_qzDOvkjLLfg_to84QvrO_A$>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
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 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? |
|
I'm not sure what the problem this PR is trying to solve. I threw together a quick gist to see what happens (at least as far back as 4.7.0 which I happen to have a scons-local on the computer). Running with a missing input file that SCons knows how to generate correctly populates the build tree. But for a file that SCons does not know how to build, it is not present. The compilation properly stops as expected with cd . && pdflatex -interaction=nonstopmode -recorder main.tex
This is pdfTeX, Version 3.141592653-2.6-1.40.26 (TeX Live 2024) (preloaded format=pdflatex)
restricted \write18 enabled.
entering extended mode
(/Users/<me>/Development/mwe/main.tex
LaTeX2e <2023-11-01> patch level 1
L3 programming layer <2024-02-20>
(/usr/local/texlive/2024/texmf-dist/tex/latex/base/article.cls
Document Class: article 2023/05/17 v1.4n Standard LaTeX document class
(/usr/local/texlive/2024/texmf-dist/tex/latex/base/size10.clo))
! LaTeX Error: File `missing.tex' not found.
Type X to quit or <RETURN> to proceed,
or enter new name. (Default extension: tex)
Enter file name:
! Emergency stop.
<read *>
l.3 \input{missing}
^^M
! ==> Fatal error occurred, no output PDF file produced!
Transcript written on main.log.
pdflatex returned an error, check the log file
scons: *** [main.pdf] Error 1I agree with @mwichmann that this should be treated as a system file that SCons wouldn't know how to regenerate. This would hit hard for "standard" packages distributed in TeXLive like If the user wanted to do something like \documentclass{article}
\usepackage{scons}
...Then they should have done something along the lines of sty = env.Command("scons.sty", ["scons.ins", "scans.idtx"], "$PDFLATEX ${SOURCE.file}", chdir=1)to teach SCons how to do the Right Thing™. I would say the main add on this PR is the (noted) incomplete test, but is that wanted? |
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=alloutput and then we get an error frompdflatexwhen 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:
CHANGES.txt(and read theREADME.rst)