Host configuration #1929

Closed
wants to merge 2 commits into
from

Conversation

Projects
None yet
2 participants
@voxik
Contributor

voxik commented Sep 27, 2012

These configure options mimic standard autoconf options. The --build is
guessed by default, but it has no real meaning ATM. The --host defaults
to BUILD value, but can be overridden, to specify the platform Rubinius will
run on. This could be used for cross-compilation in the future. At now,
it helps to recognize vendor properly.

voxik added some commits Sep 27, 2012

Dealy initialization of configuration options.
This allows to specify host by configuration parameters.
Add --build and --host configure options.
These configure options mimic standard autoconf options. The --build is
guessed by default, but it has no real meaning ATM. The --host defaults
to BUILD value, but can be overridden, to specify the platform Rubinius will
run on. This could be used for cross-compilation in the future. At now,
it helps to recognize vendor properly.
@voxik

This comment has been minimized.

Show comment Hide comment
@voxik

voxik Sep 27, 2012

Contributor

Just for illustration, Rubinius reported itself as

rubinius 2.0.0dev (1.8.7 release yyyy-mm-dd JI) [x86_64-unknown-linux-gnu]

while with this configuration option, it reports

rubinius 2.0.0dev (1.9.3 release yyyy-mm-dd JI) [x86_64-redhat-linux-gnu]

This applies to Fedora builds using standard configuration options.

Contributor

voxik commented Sep 27, 2012

Just for illustration, Rubinius reported itself as

rubinius 2.0.0dev (1.8.7 release yyyy-mm-dd JI) [x86_64-unknown-linux-gnu]

while with this configuration option, it reports

rubinius 2.0.0dev (1.9.3 release yyyy-mm-dd JI) [x86_64-redhat-linux-gnu]

This applies to Fedora builds using standard configuration options.

@brixen

This comment has been minimized.

Show comment Hide comment
@brixen

brixen Sep 28, 2012

Member

Why did you move the code out of #initialize?

Member

brixen commented Sep 28, 2012

Why did you move the code out of #initialize?

@voxik

This comment has been minimized.

Show comment Hide comment
@voxik

voxik Sep 30, 2012

Contributor

I moved it, because there are done some actions based on detected host. But since the host can be overridden by the --host flag, they have to be done later.

Contributor

voxik commented Sep 30, 2012

I moved it, because there are done some actions based on detected host. But since the host can be overridden by the --host flag, they have to be done later.

@brixen

This comment has been minimized.

Show comment Hide comment
@brixen

brixen Oct 1, 2012

Member

There are a number of places where multiple values have to be updated when an option is processed. Just update what needs to be set in the --host option.

Member

brixen commented Oct 1, 2012

There are a number of places where multiple values have to be updated when an option is processed. Just update what needs to be set in the --host option.

@brixen

This comment has been minimized.

Show comment Hide comment
@brixen

brixen Oct 1, 2012

Member

There is a terrible tangle of dependencies around the code in #initialize. I mostly untangled them. I'll push a commit that adds --host shortly. Unless you give me a compelling reason for --build right now, I'm not adding it. "We might need something like this" won't suffice.

Member

brixen commented Oct 1, 2012

There is a terrible tangle of dependencies around the code in #initialize. I mostly untangled them. I'll push a commit that adds --host shortly. Unless you give me a compelling reason for --build right now, I'm not adding it. "We might need something like this" won't suffice.

@voxik

This comment has been minimized.

Show comment Hide comment
@voxik

voxik Oct 2, 2012

Contributor

Well, the truth is that I'd love to see merged this [1] branch. This would allow to feed in various standard options which can be consumed by typical configure script generated by autotools and it would make packaging for Fedora more foolproof (i.e. I would be able to use standard %{configure} macro instead of specifying each configuration option one by one). So I would not cry for the --build all that much.

[1] https://github.com/voxik/rubinius/commits/accept-standard-configure-options/

Contributor

voxik commented Oct 2, 2012

Well, the truth is that I'd love to see merged this [1] branch. This would allow to feed in various standard options which can be consumed by typical configure script generated by autotools and it would make packaging for Fedora more foolproof (i.e. I would be able to use standard %{configure} macro instead of specifying each configuration option one by one). So I would not cry for the --build all that much.

[1] https://github.com/voxik/rubinius/commits/accept-standard-configure-options/

@brixen brixen closed this in a1d6985 Oct 3, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment