More fixes for standalone build and CI - #2
Merged
Merged
Conversation
…k build tree, esp FORTRAN tests - Drop requirement for (rather old) starlink fork of automake - Brought in my own replacements for the bare minimum set of routines from Starlink libraries needed for the tests; written in C which I'm more comfortable with, but with gfortran name mangling applied, following the conventions from the macros in f77.h; some of this is probably still buggy but the tests pass - Bring the Fortran tests more into the automake build system
…ed tests add a Makefile.am in ast_tester and move fortran test definitions there, and hook them properly into automake's test runner Now there are two test suites: ast_tester/ and ast_tests/ I believe this will still all work the same otherwise when building in the Starlink environment but this needs to be confirmed.
default boostrap for out-of-starlink builds Provides some minimal necessary STAR_ m4 macros needed for the build.
within the Starlink build environment Takes further steps (including handling of the default Starlink m4 macros) to separate the 'local' build initiated with bootstrap.local from the standard Starlink build initialized by bootstrap
built by the makefile
I misunderstood exactly what that macro was for at first and thought it was a replacement for AC_CONFIG_FILES somehow. The safest bet seems to be to copy the macro implementation from starconf and leave the rest of the Makefile.am alone.
Previously I didn't fully grok what this messgen stuff was about. Now I do. Rather than try to cobble together an alternate solution the cleanest seems to be to just include a copy of the messgen.c source in the star_compat directory and build it as part of the standalone AST build, and use it to generate ast_err.h This is already handled in the normal Starlink-based build, and is supported by Starlink's patch automake. Here we don't have that, so we have to do the same thing with standard automake targets
I previously overlooked the fact that there were some C tests already run by ast_tester/ , so this adds them to the `make check` suite as well, and also includes the ast_test.c smoke test in the suite.
account for that change following rebase ; "mers.h" is included in the file but I'm not exactly sure how it's used except for defines already in "sae_par.h", so just make a small stub for it
compatibility In particular, on the macOS build it seems that newer versions of autoconf, at least on clang, check for C23 support (probably as part of AC_PROG_CC) and set it if so. Might be best to try to disable this, but rather than fighting autoconf for now it still makes sense to reformat that code.
embray
changed the title
Hopefully we can safely move away from that now.
Could also just install gcc and use that but I thought it would be intersting to try keeping things within the LLVM ecosystem. `-fallow-argument-mismatch` is not recognized on flang (apparently it is the default behavior), and neither is `-fno-range-check`; from my local experiments it seems the tests can still pass without them.
gfortran was apparently more permissive about this in its default settings than flang, and there are hundreds of these warnings in the tests. It's pretty harmless though so just silence it to clean up the build output a bit.
platform-specific differences in the results, showing up when built on macOS with clang Might not be easy to track down the source of the differences, but they are very small. Instead of using plain `diff` use a simple Python utility (if Python is available) to diff with a small amount of numerical tolerance.
Owner
Author
|
Gonna go ahead and merge this into the master branch of my fork so I can continue to use it more easily in the meantime. |
timj
added a commit
that referenced
this pull request
Aug 31, 2026
The three LaTeX2HTML macros AST uses are defined in LaTeX2HTML 95.1's
html.sty, a copy of which sits in $STARLINK/bin/sst. Cite it rather than
reasoning from first principles, and say exactly where we depart from it:
\htmlref #1 -- as html.sty
\htmladdnormallink #1 -- widened to \href
\htmladdnormallinkfoot #1\footnote{#2} -- widened to \href
\htmlref is byte-for-byte html.sty's definition, so the earlier choice to
render the text and drop the label was right for a better reason than the
one recorded: it is what these documents were written against. The two
link commands drop or plain-print the URL because html.sty targets paper;
these are PDFs with hyperref loaded, so both become live links. Nothing
printed changes either way.
AST uses no other macro from that family -- \htmlref 3248 times,
\htmladdnormallinkfoot 4, \htmladdnormallink 2, and nothing else -- so
three definitions here beat vendoring all 231 lines of html.sty, which
carries no licence statement of its own.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I misunderstood exactly what the
STAR_PREDIST_SOURCESmacro was for at first and thought it was a replacement for AC_CONFIG_FILES somehow. The safest bet seems to be to copy the macro implementation from starconf and leave the rest of the Makefile.am alone.Also need to add support for messgen in the standalone build. While it might be easy enough to cobble together a clone of it the safest bet is to just copy the relatively small and independent source for messgen.c and incorporate it into the build.