-
-
Notifications
You must be signed in to change notification settings - Fork 457
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Build unsupported #1628
base: main
Are you sure you want to change the base?
Build unsupported #1628
Conversation
configure.ac
Outdated
[Force build as an unsupported platform]) | ||
], | ||
[if test "x$enable_build_as_unsupported" = "xyes"; then | ||
host_os="unsupported" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you did it wrong. You should use the variablemy_htop_platform
. host_os
is an Autoconf-reserved variable that might imply a cross-compiler should be used.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a personal idea: I don't like adding a configure option for something that is meant for developers (porting to new platforms).
I think an easier method is to allow an undocumented override of my_htop_platform
, and then a builder can run configure like this:
export my_htop_platform=unsupported; ./configure --enable-werror --enable-unicode
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently there's no easy way to influence my_htop_platform
without duplicating much of the platform selection logic. And I'd actually also be fine if compiling for the unsupported
platform was treated/handled as a cross-build.
I think, if we want to keep host_os
untouched, we could initialize htop_host_os
as host_os
and do the override on htop_host_os
.
I'm open to alternate suggestions. The goal for this PR is mostly to get the code for the unsupported
platform into the usual CI builds, and using an explicit configure switch seemed like the most straight forward solution to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@BenBE The problem with --enable-build-as-unsupported
is that it conflicts with --enable-pcp
as both options would override my_htop_platform
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also noticed, that ./configure --host=none
seems to work equally well …
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@BenBE That's perhaps unintentional. You should specify --host=x86_64-unknown-unsupported_os
instead. That's the "target triplet" format.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope, that's intentional and correct, as config.sub
translates single-part information into the full triplet.
Cf. config.sub for the full implementation …
FWIW:
$ ./configure --host=x86_64-unknown-unsupported_os
checking build system type... x86_64-pc-linux-gnu
checking host system type... Invalid configuration `x86_64-unknown-unsupported_os': OS `unsupported_os' not recognized
configure: error: /bin/bash ./build-aux/config.sub x86_64-unknown-unsupported_os failed
A full, arch-independent version could be:
$ ./configure --host=$(uname -m)-unknown-none
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After a bit of thinking, I now believe your approach ./configure --host=$(uname -m)-none
might be the cleanest one. As long as there is no cross-compiler named $(uname -m)-none-gcc
, configure
would be happy to grab the native compiler to do what we've intended.
This allows to run configure in a way such that the current platform is treated as an unsupported one.
This is mainly intended to allow for testing consistency of the code inside the
unsupported
platform directory.