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