Consider renaming build

[ahojukka5]

This library is not compatible with a "standard" cmake build

mkdir build && cd build
cmake ..
make

because the source files are in a directory called "build" (which is kind of non-intuitive anyway..). To make this library easier to use in applications, I would suggest restructuring the package (applying) as follows (https://hsf-training.github.io/hsf-training-cmake-webpage/06-projectstructure/index.html):

code/03-structure/
├── CMakeLists.txt
├── README.md
├── apps
│   ├── CMakeLists.txt
│   └── app.cpp
├── cmake
│   └── FindSomeLib.cmake
├── docs
│   ├── CMakeLists.txt
│   └── mainpage.md
├── include
│   └── modern
│       └── lib.hpp
├── src
│   ├── CMakeLists.txt
│   └── lib.cpp
└── tests
    ├── CMakeLists.txt
    └── testlib.cpp

• external api published in include/p3dfft.3/p3dfft.h (or should it be p3dfft.3.h?)
• internal header files and source files in src
• tests in tests

[dmitrypek]

Thank you for all of your suggestions. One thing to clarify: for users of the library the internal structure should not be an issue. We are not using cmake at this time, instead we are using autoconf. Users can specify --prefix in configure options, which will install the library in the location of their choice, with include/, lib/ and share/ directories. I like your idea of separating the internal and external header files, and will work on it.