Skip to content

Don't overwrite the installed pyscf's config.h - #221

Open
MatthewRHermes wants to merge 1 commit into
pyscf:masterfrom
MatthewRHermes:config_h
Open

MatthewRHermes wants to merge 1 commit into
pyscf:masterfrom
MatthewRHermes:config_h

Conversation

@MatthewRHermes

@MatthewRHermes MatthewRHermes commented Oct 9, 2026 •

Copy link
Copy Markdown
Collaborator

TL;DR oops I made this package overwrite stuff from another package at configure time 3 years ago, let's fix that

pyscf/lib/CMakeLists.txt runs configure_file on ${PYSCF_SOURCE_DIR}/lib/config.h.in and writes the result to ${PYSCF_SOURCE_DIR}/lib/config.h, i.e. into the installed pyscf. Since the template is filled in with forge's CMake variables, and forge does not define XCFUN_MAX_ORDER, every forge build replaces core's

#define XCFUN_MAX_DERIV_ORDER 3

with

#define XCFUN_MAX_DERIV_ORDER 

For a pip-installed pyscf this silently edits a file in site-packages. For a source-built pyscf, it leaves core's dft/xcfun_itrf.c (int XCFUN_max_deriv_order = XCFUN_MAX_DERIV_ORDER;) unable to compile until core is reconfigured. The file is gitignored in pyscf, so git status doesn't show it.

This line was added in #8 because the pyscf wheels of the time shipped only config.h.in. That is no longer the case:

pyscf wheel config.h.in config.h
2.1.1 ✅ ❌
2.2.0, 2.2.1, 2.3.0, 2.14.0 ✅ ✅

This PR uses pyscf's config.h as installed, so forge sees the values pyscf was actually built with. Only if it is missing (pyscf < 2.2) is it generated, into the build directory, which goes first on the include path. In that case there is no XCFUN macro to get wrong: 2.1.1's config.h.in doesn't have one. No forge C code currently uses XCFUN_MAX_DERIV_ORDER or HAVE_FFS; the files that include config.h (lno/ccsd_t.c, lno/uccsd_t.c, pwscf/pwscf.c, dsrg/dsrg_helper.c) only need the OpenMP stubs.

Tested locally (Linux, CMake 4.3.2, conda env with a source-built pyscf 2.14.0):

  • pyscf has config.h: build succeeds and the installed config.h is unchanged (md5 before/after); master overwrites it in the same setup. All 8 forge .so files have disassembly identical to a master build.
  • pyscf without config.h (-DPYSCF_SOURCE_DIR pointed at a copy of core's lib/ minus config.h): config.h is generated in the build directory, nothing is written to the pyscf copy, build succeeds.

(PR composed by Claude Opus 5.5 following a conversation with me locally)

🤖 Generated with Claude Code

pyscf/lib/CMakeLists.txt ran configure_file on
${PYSCF_SOURCE_DIR}/lib/config.h.in with forge's own CMake variables
and wrote the result to ${PYSCF_SOURCE_DIR}/lib/config.h, i.e. into
the installed pyscf. Forge does not define XCFUN_MAX_ORDER, so every
forge build replaced core's "#define XCFUN_MAX_DERIV_ORDER 3" with an
empty definition, which core's dft/xcfun_itrf.c cannot compile against.

Use pyscf's config.h as installed. It has shipped in wheels since
pyscf 2.2; only older wheels (e.g. 2.1.1, whose config.h.in has no
XCFUN macro) lack it, and in that case generate it in the build
directory instead.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant