cburstedde / p4est

The "p4est" forest-of-octrees library
www.p4est.org/
GNU General Public License v2.0
251 stars 114 forks source link

two sc_config.h created. Which is which? #312

Open LukasvdWiel opened 2 months ago

LukasvdWiel commented 2 months ago

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 commented 2 months ago

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 commented 2 months ago

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