Skip to content

Update patch for CSDP Makefile - #4654

Open
d-torrance wants to merge 2 commits into
Macaulay2:developmentfrom
d-torrance:csdp
Open

Update patch for CSDP Makefile#4654
d-torrance wants to merge 2 commits into
Macaulay2:developmentfrom
d-torrance:csdp

Conversation

@d-torrance

@d-torrance d-torrance commented Aug 17, 2026

Copy link
Copy Markdown
Member

We update our patch for the CSDP Makefile so it's more configurable.

Right now we have to do some goofy hacks to get it to work with our build, and it breaks in strange places, e.g.:

$ make -C libraries/csdp CFLAGS=-O2
make: Entering directory '/home/profzoom/src/macaulay2/M2/M2/BUILD/build/libraries/csdp'
=== remaking .compiled-6.2.0 in csdp :
===   -rw-rw-r-- 1 profzoom profzoom 0 Aug 16 20:30 .compiled-6.2.0
===   -rw-rw-r-- 1 profzoom profzoom 0 Aug 16 21:04 .configured-6.2.0
+ set +x
make: Entering directory '/home/profzoom/src/macaulay2/M2/M2/BUILD/build/libraries/csdp/build/Csdp-6.2.0'
+ make -j1 prefix=/home/profzoom/src/macaulay2/M2/M2/BUILD/build/usr-host CC=gcc -fopenmp CXX=g++ -fopenmp LDFLAGS=-L/home/profzoom/src/macaulay2/M2/M2/BUILD/build/usr-host/lib -g3 -L/usr/lib/x86_64-linux-gnu -fopenmp LDLIBS=  LIBS=-L../lib -lsdp  -lopenblas  -L/usr/lib/gcc/x86_64-linux-gnu/13 -L/usr/lib/gcc/x86_64-linux-gnu/13/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/13/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/13/../../.. -lglpk -lmps -lmpfi -lmpfr -lgmpxx -lgmp -lgc -lgdbm -lgfortran -lm -lquadmath -lm
make[1]: Entering directory '/home/profzoom/src/macaulay2/M2/M2/BUILD/build/libraries/csdp/build/Csdp-6.2.0'
make -C lib libsdp.a
make[2]: Entering directory '/home/profzoom/src/macaulay2/M2/M2/BUILD/build/libraries/csdp/build/Csdp-6.2.0/lib'
gcc -fopenmp -O2   -c -o readprob.o readprob.c
readprob.c:10:10: fatal error: declarations.h: No such file or directory
   10 | #include "declarations.h"
      |          ^~~~~~~~~~~~~~~~
compilation terminated.

That's because setting CFLAGS at the command line overwrote the -I../include flag we needed to find the headers!

I just uploaded the same patch for the Debian package and plan to update the spack and Homebrew packages soon, too. The changes are also submitted upstream at coin-or/Csdp#22.

🤖 AI Disclosure 🤖

Claude wrote the first draft of the Makefile patch, and together we made a ton of revisions. It also helped put the together the M2 side of it in M2/libraries/csdp/Makefile.in and M2/cmake/build-libraries.cmake.


Draft for now to test the builds.

Edit: Builds passed!

@d-torrance d-torrance added dependencies Pull requests that update a dependency file AI-generated This PR contains AI-generated code build issue platform specific issues involving compiling M2, generating examples, or running tests labels Aug 17, 2026
@d-torrance

d-torrance commented Aug 17, 2026

Copy link
Copy Markdown
Member Author

I added a related cmake fix to a change I made in #4059. If we pass CFLAGS= or CXXFLAGS=, then we get nothing in these flags when building dependencies. In particular, no optimization!

So now we also pass the build type's optimization flags. They go after the the user flags, overwriting them when they conflict, but Claude swears up and down that's cmake's convention.

CMAKE_C_FLAGS holds only the flags meant for every configuration; the
build type's optimization level lives in the per-configuration variables,
CMAKE_C_FLAGS_RELEASE and friends.  We forwarded just the former, so
unless the user exported CFLAGS we handed each dependency an empty one.
Set but empty also suppresses autoconf's -g -O2 fallback, since
${CFLAGS+y} counts an empty value as set.

How much that mattered varies by dependency.  The ones with a configure
script largely fill the gap themselves: factory's puts -O3 in CXXFLAGS
when the caller does not, so it built the same either way.  The ones left
with no -O at all are the three whose hand written makefile takes CFLAGS
from the command line and has no configure to fall back on: cohomcalg,
csdp and lrslib.

The per-configuration flags go last, matching the order cmake uses for
our own targets, which means that for a flag like -O, where the last one
wins, the build type has the final say over an exported CFLAGS.

CMAKE_BUILD_TYPE holds what the user typed, e.g. Release, while the
variables are spelled CMAKE_C_FLAGS_RELEASE, hence the TOUPPER; without
it the lookup names a variable that does not exist and quietly expands to
nothing.

Csdp is where this became visible: its new makefile honors a CFLAGS given
on the command line, so the empty value we were passing left it compiling
at -O0.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@d-torrance
d-torrance marked this pull request as ready for review August 18, 2026 00:32

@andrew-tawfeek andrew-tawfeek left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

This looks good. I applied the patch to CSDP 6.2.0 and built it on macOS with explicit caller CFLAGS, CPPFLAGS, and LDFLAGS plus libomp and Accelerate. Both CSDP tests passed through the patched CMake target, and a Release configure forwarded the general and configuration-specific compiler flags in the expected order.

AI-assisted PR review alongside GPT 5.6-Sol

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

Labels

AI-generated This PR contains AI-generated code build issue platform specific issues involving compiling M2, generating examples, or running tests dependencies Pull requests that update a dependency file

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants