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

Support for build/host/target #4022

Closed
Jehan opened this Issue Aug 14, 2018 · 8 comments

Comments

Projects
None yet
3 participants
@Jehan

Jehan commented Aug 14, 2018

The cross build definition file is good, but most cross-compilation (especially when the build files are well written) really do not need to define every single details. Setting the host machine (i.e. the prefix used for the binaries) is usually necessary. I.e. in autotools, we get:

./configure --host=i686-w64-mingw32

And done. You build for Windows 32-bit with generic options. Of course, adding the concept of build (default to native build machine) and target (for compilers and alike) is good too (what they call Canadian Cross compilation, if not mistaken).

As far as I could find, meson does not provide this possibility yet. You have to write an exhaustive toolchain file where you list all the binaries in particular (even though they are all just the common tool name prefixed with the host name). Then regularly, as you come into a project using another tool, the cross-build version is not detected by meson automatically (as it should) and you have to diagnose, then add a binary in your list (oups, this uses i686-w64-mingw32-ar, oh and this one i686-w64-mingw32-windres, etc.). That's not the cleverest way to handle cross-compilation.

Note that I am not saying that you should remove toolchain files. They sure could get useful for specific project (what if some alternative tool does not use the standard prefixed naming? Or if whatever specific option is necessary for your build?). But this should an advanced option. A simpler method using the trio build/host/target is definitely the best default way to handle this.

@jpakkane

This comment has been minimized.

Show comment
Hide comment
@jpakkane

jpakkane Aug 14, 2018

Member

As far as I could find, meson does not provide this possibility yet.

That is correct. Nor do we intend to, because:

That's not the cleverest way to handle cross-compilation.

Perhaps, but it is the most explicit, simple, readable and understandable. Especially for people unfamiliar with the intricacies of the GNU toolchain.

Member

jpakkane commented Aug 14, 2018

As far as I could find, meson does not provide this possibility yet.

That is correct. Nor do we intend to, because:

That's not the cleverest way to handle cross-compilation.

Perhaps, but it is the most explicit, simple, readable and understandable. Especially for people unfamiliar with the intricacies of the GNU toolchain.

@Jehan

This comment has been minimized.

Show comment
Hide comment
@Jehan

Jehan Aug 14, 2018

I see. Is the concept of prefixed tools (i.e. the exact same name but prefixed with the host platform) really a specificity of the GNU toolchain? I indeed am mostly used to cross-compilation on Linux (where this is clearly a de-facto standard) so I may be missing different usage elsewhere. :-)

In the end, you decide, though I would appreciate if you could reconsider. I remind I am not asking to get rid of the concept of toolchain file. Such usage for host prefix would be explicit, and everyone would be free to not set such value and still list every binary as before.

Alternatively this could be implemented as another field in the toolchain file (which could be overrided by any specific binary field), rather than a command line option too. For instance, say you build for Windows 32-bit with Mingw64, you could set:

[binaries]
host = 'i686-w64-mingw32'
strip = 'mystrip'

This way, by default, it would just look for every default binary prefixed with 686-w64-mingw32 (i.e. if for instance i686-w64-mingw32-pkg-config exists, it is used as pkg-config instead of pkg-config). But you could still specify your own binary if it doesn't follow this naming standard (for instance, in my example above, if my equivalent of strip was called mystrip instead of being prefixed, I would set it; but no need to set i686-w64-mingw32-gcc, etc.).

Nobody would be forced to set a host and could still just make a long list of all the binaries if preferred.

Note that if you don't care personally about the feature, but are not against it, I would not mind giving it a try and implement it. :-)

For the record, I regularly cross-compile (mostly because I develop GIMP, and as you may know, it is also available for Windows) and this would help. I actually don't see a downside to this feature.

Edit: when I said "That's not the cleverest way to handle cross-compilation", I didn't mean anything insulting by it. I wanted to write this down here, just in case, as after re-reading, this may sound not-nice. That was not the intention.

Jehan commented Aug 14, 2018

I see. Is the concept of prefixed tools (i.e. the exact same name but prefixed with the host platform) really a specificity of the GNU toolchain? I indeed am mostly used to cross-compilation on Linux (where this is clearly a de-facto standard) so I may be missing different usage elsewhere. :-)

In the end, you decide, though I would appreciate if you could reconsider. I remind I am not asking to get rid of the concept of toolchain file. Such usage for host prefix would be explicit, and everyone would be free to not set such value and still list every binary as before.

Alternatively this could be implemented as another field in the toolchain file (which could be overrided by any specific binary field), rather than a command line option too. For instance, say you build for Windows 32-bit with Mingw64, you could set:

[binaries]
host = 'i686-w64-mingw32'
strip = 'mystrip'

This way, by default, it would just look for every default binary prefixed with 686-w64-mingw32 (i.e. if for instance i686-w64-mingw32-pkg-config exists, it is used as pkg-config instead of pkg-config). But you could still specify your own binary if it doesn't follow this naming standard (for instance, in my example above, if my equivalent of strip was called mystrip instead of being prefixed, I would set it; but no need to set i686-w64-mingw32-gcc, etc.).

Nobody would be forced to set a host and could still just make a long list of all the binaries if preferred.

Note that if you don't care personally about the feature, but are not against it, I would not mind giving it a try and implement it. :-)

For the record, I regularly cross-compile (mostly because I develop GIMP, and as you may know, it is also available for Windows) and this would help. I actually don't see a downside to this feature.

Edit: when I said "That's not the cleverest way to handle cross-compilation", I didn't mean anything insulting by it. I wanted to write this down here, just in case, as after re-reading, this may sound not-nice. That was not the intention.

@dcbaker

This comment has been minimized.

Show comment
Hide comment
@dcbaker

dcbaker Aug 14, 2018

Contributor

I added support for system wide cross files some time ago, i'd really hoped that distros would generate the cross files and distribute them at the system level so you could just do something like meson --cross-file i686-w64-mingw32, since there would be a correct cross file in a system location called i686-w64-mingw32, I don't know whether distro's didn't notice or didn't care.

Contributor

dcbaker commented Aug 14, 2018

I added support for system wide cross files some time ago, i'd really hoped that distros would generate the cross files and distribute them at the system level so you could just do something like meson --cross-file i686-w64-mingw32, since there would be a correct cross file in a system location called i686-w64-mingw32, I don't know whether distro's didn't notice or didn't care.

@Jehan

This comment has been minimized.

Show comment
Hide comment
@Jehan

Jehan Aug 14, 2018

Actually I do have a series of toolchain files already (for Windows 32/64-bit, for the various Android targets, etc.), which is basically good for most projects (all the ones I needed to build so far). From time to time, I encounter a project where I have to edit it, but that becomes rarer (looking my logs, last one was in June, when I had to add a windres).

Really this is more of a nitpicking/perfection-making point of view that I am speaking here as I could do without and each time, when I encountered such issues (as I'm sure I will again), I can diagnose the error messages and fix them by adding the needed binary. Yet on this perfection-making point of view, all these error diagnosis, even though rare, are still a waste of time. Each time, the tools which were needed were prefixed-version of the native tool so they could just as well have been found by meson anyway (if they were already installed), or meson could have even warned by itself if it didn't find them (as autotools does with some macro which are cross-compilation aware).

I just can't see why you would not want this in meson (while still keeping the possibility to override the general prefix rule on a per-tool basis). :-)

Jehan commented Aug 14, 2018

Actually I do have a series of toolchain files already (for Windows 32/64-bit, for the various Android targets, etc.), which is basically good for most projects (all the ones I needed to build so far). From time to time, I encounter a project where I have to edit it, but that becomes rarer (looking my logs, last one was in June, when I had to add a windres).

Really this is more of a nitpicking/perfection-making point of view that I am speaking here as I could do without and each time, when I encountered such issues (as I'm sure I will again), I can diagnose the error messages and fix them by adding the needed binary. Yet on this perfection-making point of view, all these error diagnosis, even though rare, are still a waste of time. Each time, the tools which were needed were prefixed-version of the native tool so they could just as well have been found by meson anyway (if they were already installed), or meson could have even warned by itself if it didn't find them (as autotools does with some macro which are cross-compilation aware).

I just can't see why you would not want this in meson (while still keeping the possibility to override the general prefix rule on a per-tool basis). :-)

@dcbaker

This comment has been minimized.

Show comment
Hide comment
@dcbaker

dcbaker Aug 14, 2018

Contributor

As Jussi said, it's something the gnu-centric. It doesn't even make sense for other open source compiler stacks like LLVM/clang, since a single LLVM can have multiple backends, unlike GCC in which one binary has one backend.

The reality is that a distro maintainer is better positioned to solve these issues than the end user is for distro provided toolchains, they are aware of changes to the toolchain (new versions, new paths, etc), and they can set up the correct dependencies in the packages to make everything work the way you really want them to.

Contributor

dcbaker commented Aug 14, 2018

As Jussi said, it's something the gnu-centric. It doesn't even make sense for other open source compiler stacks like LLVM/clang, since a single LLVM can have multiple backends, unlike GCC in which one binary has one backend.

The reality is that a distro maintainer is better positioned to solve these issues than the end user is for distro provided toolchains, they are aware of changes to the toolchain (new versions, new paths, etc), and they can set up the correct dependencies in the packages to make everything work the way you really want them to.

@jpakkane

This comment has been minimized.

Show comment
Hide comment
@jpakkane

jpakkane Aug 14, 2018

Member

A very simple way of taking something simple and usable and making it awful is to add a million, billion, gazillion options and ways of doing things. The design of Meson (like of Python) is to have one, and preferably only one, obvious way of doing anything.

Member

jpakkane commented Aug 14, 2018

A very simple way of taking something simple and usable and making it awful is to add a million, billion, gazillion options and ways of doing things. The design of Meson (like of Python) is to have one, and preferably only one, obvious way of doing anything.

@Jehan

This comment has been minimized.

Show comment
Hide comment
@Jehan

Jehan Aug 15, 2018

have one, and preferably only one, obvious way of doing anything.

I don't see my proposition as a different way, but as a "default" settings which can be set, and overrided on case-per-case basis. :-)

Anyway I see your point and it doesn't seem like I would change your mind. I still think having the possibility to have a default prefix for a given backend would be a nice thing to have (even though probably quite GNU-centric way, I didn't really know this), but there is no point to discuss this forever. Also I understand what you mean. It makes sense too.

And just to make sure: if I were to propose a pull request (i.e. if I implemented this myself), it would be refused, right?
If so, I guess you can just close. ;-)

Jehan commented Aug 15, 2018

have one, and preferably only one, obvious way of doing anything.

I don't see my proposition as a different way, but as a "default" settings which can be set, and overrided on case-per-case basis. :-)

Anyway I see your point and it doesn't seem like I would change your mind. I still think having the possibility to have a default prefix for a given backend would be a nice thing to have (even though probably quite GNU-centric way, I didn't really know this), but there is no point to discuss this forever. Also I understand what you mean. It makes sense too.

And just to make sure: if I were to propose a pull request (i.e. if I implemented this myself), it would be refused, right?
If so, I guess you can just close. ;-)

@jpakkane

This comment has been minimized.

Show comment
Hide comment
@jpakkane

jpakkane Aug 15, 2018

Member

If so, I guess you can just close. ;-)

Closing.

Member

jpakkane commented Aug 15, 2018

If so, I guess you can just close. ;-)

Closing.

@jpakkane jpakkane closed this Aug 15, 2018

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