Compilation of DAKOTA problem with NIDR_keywds0.h

[Ramzy1990]

Hi everyone,

I am having issues compiling DAKOTA through different versions of Linux: CentOS and Ubuntu versions > 20.04.

Attached please find the CMake output, and here is the error message I am getting:

[ 27%] Built target soga
[ 27%] Generating ../generated/src/NIDR_keywds0.h

../packages/external/nidr/nidrgen:
botch on line 1 of "/home/mraltahh/dakota/6.19/source/dakota-6.19.0-public-src-cli/src/dakota.input.nspec":
" unexpected.
make[2]: *** [src/CMakeFiles/dakota_order_input.dir/build.make:75: generated/src/NIDR_keywds0.h] Error 1
make[2]: *** Deleting file 'generated/src/NIDR_keywds0.h'
make[1]: *** [CMakeFiles/Makefile2:7247: src/CMakeFiles/dakota_order_input.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

The error is driving me mad and I am not able to find a workaround for it and I am not sure what is being done wrong?! I can successfully build DAKOTA on WSL Ubuntu 20.04, but if I move to new versions or a larger cluster (running on CentOS) I am not able to compile DAKOTA due to this problem.

Some background:

1. I compiled BOOST and I am using 1.69 (just in case it is new versions of Boost problems!)
2. I am using the attached CMake script, in which I define boost locations and everything else. The MPI location is not mandatory as CMake can find it, same goes for HDF5 (I am running inside a conda environment that has all the necessary TPL, compilers, etc., except boost).

Please help and thank you!
CMakeOutput.txt
BuildDakota.txt

[briadam]

IIRC this error is sometimes caused by using a Windows .zip Dakota source archive on Linux, where the CRLF line endings trip up the NIDR utility. You might first verify you’re using the .tar.gz Unix source package.

If that’s not the cause, I would verify that the source, build, and install (CMAKE_INSTALL_PREFIX) directories are all distinct and that you’re not trying to build from within the source tree.

[Ramzy1990]

Thank you for the prompt reply Brian and help! This is indeed the case and I have used the .zip archive file in all the cases reported which is a bit funny! I always deemed .zip easier to just unzip. I also re-compiled boost with MPI and C++11 standard, but probably this is not needed maybe. In any case, DAKOTA has been compiled successfully!

Some additional information for anyone who would like to compile boost with MPI and C++11 standard; inside the project-config.jam file, add the following:
using mpi ;

and adjust the following:

# Compiler configuration. This definition will be used unless
# you already have defined some toolsets in your user-config.jam
# file.
if ! gcc in [ feature.values <toolset> ]
{
 using gcc : : path to your g++ compiler : <cxxflags>-std=c++11 ;
}

Thank you!