Add *BSD / Solaris to the CI

[fraggerfox]

Add support for building htop in DragonFlyBSD / FreeBSD / NetBSD / OpenBSD / Solaris environments in the CI workflow.

NOTE: In future, this should help catch any changes that can potentially break the BSD / Solaris builds.

Workflows adapted from btop's GHAs.

[Explorer09]

Your latest DragonFlyBSD commit (00bca18) caused a build failure, and I noticed one thing in the build log: The configure scripts detected gcc and tried to use it instead of clang. Did you notice that?

Also, the line mv htop htop-clang-"$GIT_HASH" got run even when make produced errors. (What's the purpose of this rename, by the way?)

[fraggerfox]

Your latest DragonFlyBSD commit (00bca18) caused a build failure, and I noticed one thing in the build log: The configure scripts detected gcc and tried to use it instead of clang. Did you notice that?

Yes, I was just testing out how DragonFlyBSD works, I was assuming it would be using clang instead of gcc (like in FreeBSD), but that is a minor change to do. I was more curious on the missing ncurses library. I am trying to get a copy of DragonFlyBSD to boot locally in my system so that I can check this out.

Also, the line mv htop htop-clang-"$GIT_HASH" got run even when make produced errors. (What's the purpose of this rename, by the way?)

The rename if it fails (i.e. the binary was not built) would cause the workflow to fail, I did that since it is the easiest way I could check if the build failed or not.

An example of a build failure but not a failed step can be found here

• https://github.com/htop-dev/htop/actions/runs/8029660529/job/21936201103#step:3:1724

[BenBE]

No Unicode support on NetBSD/OpenBSD?

[fraggerfox]

An example of a build failure but not a failed step can be found here

* https://github.com/htop-dev/htop/actions/runs/8029660529/job/21936201103#step:3:1724

Does a "set -e" line work within a CI script file? That could save you some || exit 1 code there.

I tested out this suggestion and it seem to have worked. Thank you.

• https://github.com/fraggerfox/htop-dev/actions/runs/8049339870/job/21982494851

I have updated the file with the changes.

[BenBE]

LGTM.

You could fixup the set -e patch into the individual platforms, but that's optional.

[Explorer09]

Add the -k option to the gmake commands. This would keep the make program running even when there's a build error on one object file. Useful for catching multiple source file errors.
(Other platform targets in this .yml file have this -k option.)

[fraggerfox]

Good idea, I have updated the command.

[BenBE]

Same should be done for regular make too … Good point.

[BenBE]

Some ideas, no need to implement them right now:

• What about ZFS support on FreeBSD/NetBSD? Shouldn't we try to build on the CI with such support enabled?
• What about PCP builds? @natoscott AFAIR PCP should build on all platforms¹, right?
• Other optional libs we should test in the CI?

¹given the right dependencies are installed

[fasterit]

What about ZFS support on FreeBSD/NetBSD? Shouldn't we try to build on the CI with such support enabled?

This is not gated by a config-flag. So it is build in automatically (on FreeBSD).
Now, having test-cases is another thing...

/DLange

[natoscott]

Some ideas, no need to implement them right now:
[...]
* What about PCP builds? @natoscott AFAIR PCP should build on all platforms¹, right?
¹given the right dependencies are installed

Yes, many platforms are supported by PCP - the issue will be ensuring the PCP bits are readily accessible on non-Linux platforms.

If possible, it'd be great to get PCP builds for non-Linux platforms here in htop.dev repo, however in practice I think it will be more practical for this to happen via the actual PCP build (which builds a vendored htop git repo via git-subtree). Perhaps best will be if we automate the sync between PCP and htop (currently its manual) so that commits here automatically trigger a PCP build.

https://github.com/performancecopilot/pcp/tree/main/vendor/github.com/htop-dev/htop

[BenBE]

@natoscott Thus it's best to skip the PCP stuff in this PR.

[Explorer09]

May I bump this PR and mention an issue of it?

The "build-openbsd-latest-gcc" CI job in commit 1fa7d6c does not actually run GCC, but Clang under the program name "cc" ! I discovered this when it build-failed in one of my commits and threw me a compile warning. Please either correct the job name or do something to let GCC run in there.

[fraggerfox]

May I bump this PR and mention an issue of it?

The "build-openbsd-latest-gcc" CI job in commit 1fa7d6c does not actually run GCC, but Clang under the program name "cc" ! I discovered this when it build-failed in one of my commits and threw me a compile warning. Please either correct the job name or do something to let GCC run in there.

You are right, I also over looked this, I can raise a PR to fix this and update the name to clang instead of gcc.