21 Jun
2024
21 Jun
'24
6:35 a.m.
Are we into bike shed territory?
It seems like cmake and autoconf are hated but then they have their fans.
I posted a makefile that was pretty portable but that was not OK because
it was GNU make? Huh?
I've been up since 12:22am (psyched for fishing, couldn't sleep) so maybe
I'm not on point, but what is the problem that this discussion is trying
to solve?
On Fri, Jun 21, 2024 at 09:35:18AM +1000, Alexis wrote:
Bakul Shah via TUHS <tuhs(a)tuhs.org> writes:
--
---
Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat
To build a set of objects you need to worry about
at least the
following:
- build recipes for each of them (which may also depend on other
things)
- configuration parameters
- dealing with differences on each platform
- third party libraries & alternatives
- toolchains (& may be cross-platform builds)
- supporting/navigating different versions of the last 3 above
You can't really precompute all this as there are far too many
combinations and they keep changing.
Both the blog author (who is a long-time sysadmin with many 'war stories')
and myself understand all that.
i believe the idea is not for precomputing to be done by _builds_, but to be
done on and for a given machine and its configuration, independent of any
specific piece of software, which is then _queried_ by builds. That
precomputation would only need to be re-run when one of the things under its
purview changes.
If i compile something on one of my OpenBSD boxen in the morning, and then
compile some other thing in the afternoon, without an OS upgrade in-between,
autoconf isn't going to find that libc.so has changed in-between. If i did
the same thing on my Gentoo box, it's theoretically possible that e.g. i've
moved from glibc to musl in-between, but in that case, precomputation could
be done in postinst (i.e. as part of the post-installation-of-musl process).
Alexis.