Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Three 8-hour days on cmake
46 views
Skip to first unread message
Frederick Gotham
Aug 26, 2020, 2:24:29 PM8/26/20
to
I work 37.5 hours a week, so that's around about 8 hours a day (I leave early on Friday's).
Today's Wednesday, and I've just finished my 3rd day in a row trying to get 'cmake' to cross-compile on an x64 host for an aarch64 target (both Linux).
Are the makers of 'cmake' mistakenly claiming that it can cross-compile? I've read their manual in the chapter about 'toolchains', but after about 22 hours at my desk scrolling through various posts on open-source forums, Github issues, and 'Stack Overflow', I still haven't got a successful aarch64 build.
It looks like I will have to do the following with every package that is built with 'cmake':
(1) Run 'cmake' natively on x64 to get it to create GNU Makefiles intended for the x64 versions of gcc, g++.
(2) Process these GNU Makefiles at the command line with something like 'make SHELL="sh -x" -n' in order to get all the compiler commands
(3) Gather all the compiler commands together into a script and call it "make.sh", and prepend "aarch64-linux-gnu-" to every command.
(4) Add these "make.sh" files to my overall build in the place of "CMakeLists.txt" and "cmake-configure".
Having spent 22 hours fiddling and tinkering around with Makefiles, I see now that they are of no use in distributed source code. Makefiles are convenient when you're _developing_ code because you don't have to recompile your entire codebase every time you make a small change, however it is only a hinderence to other people to supply your source code to them with a Makefile. You should give them a very simple compilation script -- not a horrendously complicated Makefile that creates another Makefile.
After this week I will never have the respect I once had for 'build systems'. For smaller projects I think I'll go back to simple compilation scripts like this:
#!/bin/sh
${CROSSCOMPILE}gcc -c alpha.c
${CROSSCOMPILE}gcc -c beta.c
${CROSSCOMPILE}gcc -c gamma.c
${CROSSCOMPILE}gcc -o prog alpha.o beta.o gamma.o
If someone wants to cross-compile then they can do:
CROSSCOMPILE=aarch64-linux- ./make.sh
I think 'cmake' might be able to cross-compile between Linux and MS-Windows if the two architectures are the same
, but after 22 hours I can't make an aarch64 Linux build from an x64 Linux host.
Today's Wednesday, and I've just finished my 3rd day in a row trying to get 'cmake' to cross-compile on an x64 host for an aarch64 target (both Linux).
Are the makers of 'cmake' mistakenly claiming that it can cross-compile? I've read their manual in the chapter about 'toolchains', but after about 22 hours at my desk scrolling through various posts on open-source forums, Github issues, and 'Stack Overflow', I still haven't got a successful aarch64 build.
It looks like I will have to do the following with every package that is built with 'cmake':
(1) Run 'cmake' natively on x64 to get it to create GNU Makefiles intended for the x64 versions of gcc, g++.
(2) Process these GNU Makefiles at the command line with something like 'make SHELL="sh -x" -n' in order to get all the compiler commands
(3) Gather all the compiler commands together into a script and call it "make.sh", and prepend "aarch64-linux-gnu-" to every command.
(4) Add these "make.sh" files to my overall build in the place of "CMakeLists.txt" and "cmake-configure".
Having spent 22 hours fiddling and tinkering around with Makefiles, I see now that they are of no use in distributed source code. Makefiles are convenient when you're _developing_ code because you don't have to recompile your entire codebase every time you make a small change, however it is only a hinderence to other people to supply your source code to them with a Makefile. You should give them a very simple compilation script -- not a horrendously complicated Makefile that creates another Makefile.
After this week I will never have the respect I once had for 'build systems'. For smaller projects I think I'll go back to simple compilation scripts like this:
#!/bin/sh
${CROSSCOMPILE}gcc -c alpha.c
${CROSSCOMPILE}gcc -c beta.c
${CROSSCOMPILE}gcc -c gamma.c
${CROSSCOMPILE}gcc -o prog alpha.o beta.o gamma.o
If someone wants to cross-compile then they can do:
CROSSCOMPILE=aarch64-linux- ./make.sh
I think 'cmake' might be able to cross-compile between Linux and MS-Windows if the two architectures are the same
, but after 22 hours I can't make an aarch64 Linux build from an x64 Linux host.
Cholo Lennon
Aug 26, 2020, 4:11:18 PM8/26/20
to
successful aarch64 build..." is not a good description of the issue. Are
you asking for help or is your post just a rant? :-)
--
Cholo Lennon
Bs.As.
ARG
Frederick Gotham
Aug 26, 2020, 4:52:03 PM8/26/20
to
On Wednesday, August 26, 2020 at 9:11:18 PM UTC+1, Cholo Lennon wrote:
> But it's not clear what your problem is: "...I still haven't got a
> successful aarch64 build..." is not a good description of the issue. Are
> you asking for help or is your post just a rant? :-)
If I invite you into my house and say, "There's tea in the tin and milk in the fridge", are you going to stand there staring at me until I formally ask you, "Good sir would you like a cup of tea?".
> But it's not clear what your problem is: "...I still haven't got a
> successful aarch64 build..." is not a good description of the issue. Are
> you asking for help or is your post just a rant? :-)
Please re-read my original post and fathom what I might want.
Jorgen Grahn
Aug 26, 2020, 5:36:13 PM8/26/20
to
On Wed, 2020-08-26, Frederick Gotham wrote:
...
(because one guy knew how to use it, or claimed to). We may have used
separate files for separate targets, though -- it was ten years ago,
I wasn't deeply involved, and also not very impressed by that part.
...
studying C code generated by yacc -- it's not /meant/ to be readable!
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
...
> Are the makers of 'cmake' mistakenly claiming that it can
> cross-compile? I've read their manual in the chapter about
We /did/ use cmake for cross-compilation at a previous workplace
> cross-compile? I've read their manual in the chapter about
(because one guy knew how to use it, or claimed to). We may have used
separate files for separate targets, though -- it was ten years ago,
I wasn't deeply involved, and also not very impressed by that part.
...
> Having spent 22 hours fiddling and tinkering around with Makefiles,
> I see now that they are of no use in distributed source
> code.
You're studying Makefiles generated by cmake, aren't you? That's like
> I see now that they are of no use in distributed source
> code.
studying C code generated by yacc -- it's not /meant/ to be readable!
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
David Brown
Aug 26, 2020, 5:40:02 PM8/26/20
to
Frederick Gotham
Aug 26, 2020, 5:42:23 PM8/26/20
to
On Wednesday, August 26, 2020 at 10:36:13 PM UTC+1, Jorgen Grahn wrote:
> We /did/ use cmake for cross-compilation at a previous workplace
> (because one guy knew how to use it, or claimed to). We may have used
> separate files for separate targets, though -- it was ten years ago,
> I wasn't deeply involved, and also not very impressed by that part.
It works in two cases:
> We /did/ use cmake for cross-compilation at a previous workplace
> (because one guy knew how to use it, or claimed to). We may have used
> separate files for separate targets, though -- it was ten years ago,
> I wasn't deeply involved, and also not very impressed by that part.
(1) Target = Android smartphones
(2) Host is MS-Windows, Target is Linux (and vice versa)
I haven't heard of any other case in which 'cmake' can successfully cross-compile.
Just got an email here from one of the 'cmake' maintainers, and they're having difficulty cross-compiling a Python engine for 64-Bit ARM (on an x64 host), they can do a successful build but the resultant binary doesn't work. So I think this means that I'll be dismantling all the CMakeLists.txt files I have here and just turning them into simple compilation scripts with one-liners like:
aarch64-linux-gnu-gcc -c somefile.c -o somefile.o
Siri Cruise
Aug 26, 2020, 5:49:23 PM8/26/20
to
In article <slrnrkdlds.1p...@frailea.sa.invalid>,
might need debugging and error references should point thither.
Build tools routinely trip over gnats to impale themselves on
shards of grass. The error references don't point back to the
original files.
--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
The first law of discordiamism: The more energy This post / \
to make order is nore energy made into entropy. insults Islam. Mohammed
Jorgen Grahn <grahn...@snipabacken.se> wrote:
> You're studying Makefiles generated by cmake, aren't you? That's like
> studying C code generated by yacc -- it's not /meant/ to be readable!
Yacc generated c files don't need to be debugged. The .y file
> You're studying Makefiles generated by cmake, aren't you? That's like
> studying C code generated by yacc -- it's not /meant/ to be readable!
might need debugging and error references should point thither.
Build tools routinely trip over gnats to impale themselves on
shards of grass. The error references don't point back to the
original files.
--
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @
'I desire mercy, not sacrifice.' /|\
The first law of discordiamism: The more energy This post / \
to make order is nore energy made into entropy. insults Islam. Mohammed
James Kuyper
Aug 26, 2020, 6:09:35 PM8/26/20
to
rather than, for instance, <https://discourse.cmake.org/> - what can you
expect.
Keith Thompson
Aug 26, 2020, 6:21:41 PM8/26/20
to
The advice I gave in comp.lang.c was to post a question on Stack
Overflow.
--
Keith Thompson (The_Other_Keith) Keith.S.T...@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
Vir Campestris
Aug 27, 2020, 5:09:33 PM8/27/20
to
On 26/08/2020 23:09, James Kuyper wrote:
> Well, he's asking a question about cmake in a forum devoted to C++
> rather than, for instance,<https://discourse.cmake.org/> - what can you
> expect.
Sympathy.
> Well, he's asking a question about cmake in a forum devoted to C++
> rather than, for instance,<https://discourse.cmake.org/> - what can you
> expect.
I've used cmake in the past. My experience is that when it works, it's
great. But when it goes wrong it's impossible to debug.
I think he'd agree!
Andy
Richard
Aug 27, 2020, 5:18:40 PM8/27/20
to
[Please do not mail me a copy of your followup]
Vir Campestris <vir.cam...@invalid.invalid> spake the secret code
<ri97e5$uvd$6...@dont-email.me> thusly:
>I've used cmake in the past. My experience is that when it works, it's
>great. But when it goes wrong it's impossible to debug.
This is pretty much true for all build systems.
However, CMake is widely used and lots of people have enough expertise
in it to help you solve almost any build problem with CMake.
The same can't be said for other build systems that solve the same
problems as CMake. I don't include make in this category because to
get to the same level of support as CMake, make alone doesn't cut it.
You need a portability layer of your own functions on top of make in
order to achieve the same level of functionality. ...and when I type
"make" I'm talking specifically about GNU make.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Vir Campestris <vir.cam...@invalid.invalid> spake the secret code
<ri97e5$uvd$6...@dont-email.me> thusly:
>I've used cmake in the past. My experience is that when it works, it's
>great. But when it goes wrong it's impossible to debug.
However, CMake is widely used and lots of people have enough expertise
in it to help you solve almost any build problem with CMake.
The same can't be said for other build systems that solve the same
problems as CMake. I don't include make in this category because to
get to the same level of support as CMake, make alone doesn't cut it.
You need a portability layer of your own functions on top of make in
order to achieve the same level of functionality. ...and when I type
"make" I'm talking specifically about GNU make.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
0 new messages