two sc_config.h created. Which is which?

[LukasvdWiel]

Dear p4est team,

I am trying to install p4est with MPI on a Rocky Linux 9.4 cluster.

After cmaking with P4EST_ENABLE_MPI enabled, by setting in CMakeCache.txt:

//P4EST MPI support
P4EST_ENABLE_MPI:BOOL=1

I see two nc-config.h files being generated in the build directory:

sc/include/sc_config.h
include/sc_config.h

De sc one has indeed: #define SC_ENABLE_MPI 1
The other one does not enable MPI

When I next try to build p4est, also with in

include/p4est_config.h

/* Define to 1 if we are using MPI */
#define P4EST_ENABLE_MPI 1

A conflict arises in a check src/p4est_base.h
where is validated:

#if
(defined (P4EST_ENABLE_MPI) && !defined (SC_ENABLE_MPI)) ||
(!defined (P4EST_ENABLE_MPI) && defined (SC_ENABLE_MPI))
#error "MPI configured differently in p4est and libsc"
#endif

Should I ignore the sc/include/sc_config.h,
and manually edit include/sc_config.h,
or is there more nuance to this?

Thank you for your time and expertise,

Lukas

[cburstedde]

Thanks for report! This is not intended behavior.

I am trying to install p4est with MPI on a Rocky Linux 9.4 cluster. After cmaking with P4EST_ENABLE_MPI enabled, by setting in CMakeCache.txt: //P4EST MPI support P4EST_ENABLE_MPI:BOOL=1 I see two nc-config.h files being generated in the build directory: sc/include/sc_config.h include/sc_config.h

The autotools place the config files under build_dir/config. If p4est is built with sc as a submodule, both *_config.h go there. Otherwise, each build directory gets the corresponding _config.h.

include/p4est_config.h

Again, this should not be the path. The use of -Ibuild_dir/config is automatically provided by autotools. CMake should be changed to use the same paths (config, not include) and submodule rule as the autotools. (Related: Originally, we were placing the config headers under src. We changed it to config just a few years ago. I was never happy with it and am thinking to go back to build_dir/src instead of config. But not just yet.)

Should I ignore the sc/include/sc_config.h, and manually edit include/sc_config.h, or is there more nuance to this?

Would you be in the position to help us fix the CMake include paths?

[cburstedde]

I'm pinging @scivision; maybe they know an elegant way to turn this around.

[cburstedde]

This may need some digging, maybe @mkirilin has an idea to straighten this out?

[mkirilin]

I tested p4est build by cmake with both possible options of libsc: as submodule and as an installed library. None of them demonstrates the behavior described in the topic.

I would ask @LukasvdWiel to validate the issue still persists with the latest versions of p4est and libsc develop branches.