public inbox for discuss@lists.illumos.org (since 2011-08)
 help / color / mirror / Atom feed
From: Sad Clouds <cryintothebluesky@gmail.com>
To: illumos-discuss <discuss@lists.illumos.org>
Cc: Bob Friesenhahn <bfriesen@simple.dallas.tx.us>
Subject: Re: [discuss] Binary compatibility between Illumos distributions
Date: Mon, 30 Sep 2024 17:16:33 +0100	[thread overview]
Message-ID: <20240930171633.cfe4a143fb0b3c4073ce55c6@gmail.com> (raw)
In-Reply-To: <alpine.GSO.2.20.2409300741470.4722@scrappy.simplesystems.org>

On Mon, 30 Sep 2024 08:01:04 -0500 (CDT)
Bob Friesenhahn <bfriesen@simple.dallas.tx.us> wrote:

> A good thing about autoconf is that it almost always produces the 
> correct answer, and packages depending on autoconf+automake+libtool 
> are extremely consistent and predictable.  I have found that projects 
> based on CMake are not nearly as consistent and predictable.

That may be true, however over the years I mostly used NetBSD pkgsrc to
build packages on Solaris and the experience has not always been
positive, even with software which used GNU autotools. Not only because
of the tools, but due to how the software was designed and implemented.
Autotools do not automagically make the software portable and the
usual approach of "if it works on Linux then it is good enough for us"
did not help.

These days there are a lot of different build tools and they all have
issues in various areas and none of them are perfect. I think GNU
autotools were designed at a time when Unix standards were still
evolving and there was a lot of fragmentation. However now it is much
simpler, POSIX is the dominant standard and there is a finite
combination of OS versions, compilers and linkers.

I avoid autotools and similar by following these rules:

1. Do not test for every single feature. Instead assume POSIX
compatibility and work around specific portability issues. OS name and
major/minor versions should be enough for this.

2. Use plain GNU make and create your own make files. There is no need
for portable make files, because GNU make can be built on any POSIX OS
with minimum effort.

3. Use make variables to pass specific compiler and linker options
during build. Most platforms use either GCC or Clang, but some obsolete
compilers can be easily added when needed.

4. The most important rule - do not release anything for any untested
platforms, there is a good chance the software may not work properly.
I don't have Solaris 8 or 9 to test, so they are not supported until
somebody really needs it. It is our responsibility to make sure software
works correctly. The end users should never suffer the indignity of
broken builds, runtime bugs or crashes.

------------------------------------------
illumos: illumos-discuss
Permalink: https://illumos.topicbox.com/groups/discuss/Te614dba5c9d949ba-M4afdc1b290b77c6fff49424a
Delivery options: https://illumos.topicbox.com/groups/discuss/subscription

      reply	other threads:[~2024-09-30 16:18 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-29  7:26 Sad Clouds
2024-09-29 18:25 ` Peter Tribble
2024-09-29 19:16   ` Sad Clouds
2024-09-29 19:20     ` Joshua M. Clulow via illumos-discuss
2024-09-29 20:13       ` Sad Clouds
2024-09-30 13:01         ` Bob Friesenhahn
2024-09-30 16:16           ` Sad Clouds [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240930171633.cfe4a143fb0b3c4073ce55c6@gmail.com \
    --to=cryintothebluesky@gmail.com \
    --cc=bfriesen@simple.dallas.tx.us \
    --cc=discuss@lists.illumos.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).