<div>Dear Richard,</div><div> </div><div>01.01.2021, 23:06, "Richard B. Kreckel" <<a href="mailto:kreckel@in.terlu.de" rel="noopener noreferrer">kreckel@in.terlu.de</a>>:</div><div>> Happy New Year!</div><div> </div><div>> Maintaining a second build system /is/ an additional burden and requires</div><div>> good justification. If it helps people build CLN on common platforms,</div><div>> well, that seems to be a good enough justification! That /I/ neither use</div><div>> or care about these platforms is, then, clearly subordinate.</div><div>></div><div>> On the other hand, and as a matter of fact, I have little time to debug it.</div><div> </div><div>> The existing Autotools-based build system isn't going to go away any</div><div>> time soon. It shouldn't be adversely affected by supporting CMake.</div><div>> Likewise, duplication must be kept at a minimum. The installed files</div><div>> should be the same. Etc.</div><div>></div><div>> On 28.12.20 15:33, Alexey Sheplyakov wrote:</div><div>>>  I've checked both type builds like this:</div><div>>></div><div>>>  autoreconf -i</div><div>>>  mkdir _build_autotools && cd _build_autotools && ../configure</div><div>>>  --disable-static && cd ..</div><div>>>  mkdir _build_cmake && cd _build_cmake && cmake -GNinja</div><div>>>  -DCMAKE_BUILD_TYPE=RelWithDebInfo .. && cd ..</div><div>>>  make -j4 -C _build_autotools &</div><div>>>  cmake --build _build_cmake &</div><div>>></div><div>>>  Both builds run concurrently and have completed just fine. Hence the</div><div>>>  question:</div><div>>>  could you please explain what exactly are you doing?</div><div>></div><div>> From <a href="https://github.com/asheplyakov/cln.git" rel="noopener noreferrer">https://github.com/asheplyakov/cln.git</a>, I checked out the cmake</div><div>> branch. Then:</div><div>> $ ./configure && make distclean && ./configure && make</div><div>> It seems like cl_asm.S and cl_asm_GF2.S get deleted. (Also, would it not</div><div>> be best to rename the asm files included by cl_asm.S, too?)</div><div> </div><div>Fixed. I decided to keep the old names (cl_asm_.cc, etc). If necessary they can be renamed later on.</div><div> </div><div>> Or, then I tried</div><div>> $ ./configure && make</div><div>> $ cd .. && mkdir cln_build && cd cln_build && cmake -GNinja ../cln</div><div>> $ cmake --build .</div><div> </div><div>Short answer: please run `make distclean` before starting CMake build.</div><div><div>I've added heuristcs (commit bb6e98ff6a611cc68068e4d84d49b9aa3761ef2a)</div><div>so CMake tries to detect such a broken setup and gives a helpful advice.</div><div>Alternatively you can do both CMake and autotools builds out of the tree, like this:</div></div><div> </div><div>$ mkdir  ../build_autotools && cd ../build_autotools && ../cln/configure && make</div><div>$ mkdir ../build_cmake && cd ../build_cmake && cmake -GNinja ../cln && cmake --build .</div><div><br /> </div><div>Long(er) explanation.  It's an extremely bad idea to mix in-tree and out-of-tree builds.</div><div>The problem is not CMake specific at all. Consider</div><div> </div><div>$ git clean -dfx</div><div>$ ./autogen.sh >/dev/null 2>&1 && ./configure >/dev/null 2>&1 # [1]</div><div>$ mkdir ../another_build && cd ../another_build && ../cln/configure # [2]</div><div>checking for a BSD-compatible install... /usr/bin/install -c</div><div>checking whether build environment is sane... yes</div><div>checking for a thread-safe mkdir -p... /bin/mkdir -p</div><div>checking for gawk... gawk</div><div>checking whether make sets $(MAKE)... yes</div><div>checking whether make supports nested variables... yes</div><div>configure: error: source directory already configured; run "make distclean" there first</div><div> </div><div>The first run (marked with # [1]) creates headers autoconf/cl_config.h, include/cln/host_cpu.h</div><div>(and so on) in the _source_ directory. The content of these headers depends on the OS, compiler,</div><div>and configure options (--with-gmp versus --without-gmp, or --host=arm-linux-gnueabihf).</div><div> </div><div>The second run should have created another set of platform/options dependent headers</div><div>in the _build_ directory, and add that directory to the headers search path so the compiler</div><div>can find generated headers, something like</div><div> </div><div>CPPFLAGS += -I${top_builddir}/include -I${top_builddir}/autoconf</div><div> </div><div>However the source directory is also in the header search path. Thus depending</div><div>on the order of `-I` flags "#include <cln/config.h>" might pick either cln/config.h from</div><div>the source directory (created by the first ./configure run), or cln/config.h from</div><div>the build directory (created by the 2nd run of ./configure). These files might be different.</div><div>For instance, if we do a cross compilation in `another_build` (with --host=arm-linux-gnueabihf)</div><div>cln/host_cpu.h in the source directory sets `#define __x86_64__ 1`, and the one in</div><div>the build directory `#define __arm__ 1`.</div><div>Therefore configure bails out to prevent the mess, and gives a helpful advice.</div><div> </div><div>On the other hand, if we do both builds out of the source everything is OK</div><div> </div><div>$ git clean -dfx</div><div>$ ./autogen.sh</div><div>$ mkdir ../build_native ../build_arm<br />$ cd ../build_native && ../cln/configure</div><div>$ cd ../build_arm && ../cln/configure --host=arm-linux-gnueabihf --without-gmp</div><div> </div><div> </div><div>It works the same way with CMake, except that CMake's does not detect such</div><div>broken setups automatically. However in-tree builds are not supported with</div><div>CMake (although they appear to work with some generators, for instance with</div><div>UNIX Makefiles).</div><div> <div>> and ran into the same old problems:</div><div>> 1) None of the macros {char|short|int|long}_{little|big}_endian are</div><div>> defined in cln/intparam.h.</div><div> </div><div><div>(char endianness? what's that?)</div><div> </div></div><div><div>Initially I let CMake find a 16-bit integer type and figure out its endiannes, and set</div><div>-DCL_CPU_BIG_ENDIAN_P in src/CMakeLists.txt accordingly.</div><div> </div><div><div>Now I've added "missing" {short,int,long}_{little|big}_endian macros so the definition</div><div>of CL_CPU_BIG_ENDIAN_P (in src/base/cl_sysdep.h) is the same for both CMake and</div><div>autotools builds.</div><div><div> </div><div>That said checking for endianness of both short and int is necessary for 16-bit systems</div><div>only (where both char and short might be 8-bit). I don't think anyone would run CLN on</div><div>such systems in the 21st century (computer hardware museums?). Since we require C++11</div><div>we could just check for the endianness of `int16_t`.</div><div> </div><div>These days the vast majority of CPU architectures are little endian anyway,</div><div>so the problem hardly has any practical implications.</div><div> </div></div></div><div>Hope this helps,</div><div>      Alexey</div></div></div>