search

mesonbuild / meson

The Meson Build System
http://mesonbuild.com
Apache License 2.0
5.54k stars 1.61k forks source link

Support generic POSIX C compiler #5406

Open michaelforney opened 5 years ago

michaelforney commented 5 years ago

When I try to run meson with CC set to a C compiler it doesn't know about (for instance pcc, tcc, or others), I get the error

meson.build:1:0: ERROR: Unknown compiler(s): [['pcc']]

However, pcc follows the standard POSIX compiler interface, and is perfectly capable of building the project in question. There are quite a few C compilers in the world, and I think meson should allow the build to continue even if it doesn't know about the particular one the user specified.

Perhaps this could be done by falling back to a GenericPosixCCompiler, which supports the options specified in https://pubs.opengroup.org/onlinepubs/9699919799/utilities/c99.html.

jpakkane commented 5 years ago

Even if this was done there would need to be code added to Meson that detects the compiler as something that works in the posix way based on its output. At this point you might as well add it to Meson as it does not take a lot of code, which is basically subclassing and overriding a few methods.

The bigger problem here is one of reliability and support. If we were to add a "posixlike" compiler then it really should work with all of them. We can't really support that since experience has shown that every compiler is its own unique snowflake in some way. One of the main principles of Meson is, and has always been, that we only add functionality that we know to work and can keep supporting in the future[1]. A generic "any compiler" backend does not really qualify for this.

[1] Yes, I do know our record on this is not perfect. But it is what we aim for.

michaelforney commented 5 years ago

Even if this was done there would need to be code added to Meson that detects the compiler as something that works in the posix way based on its output. At this point you might as well add it to Meson as it does not take a lot of code, which is basically subclassing and overriding a few methods.

The difference is that adding support for a particular compiler to meson solves the issue in one case, and adding support for the generic POSIX interface solves it in all cases. pcc and tcc are just two popular examples. Here's a few more:

The last one is my own C compiler I've been working on. Recently, I tried to use it to build a project using meson, and ended up just rewriting the build system in make, since that was easier than getting meson to work.

I think it's safe to assume that on POSIX systems, the compiler follows the POSIX interface. At the very least, maybe there could be a flag to tell meson that "the compiler follows the standard interface, please just use the one I specified". As it stands, it is impossible to even attempt the build with an alternative compiler, and I don't think this is acceptable behavior.

The bigger problem here is one of reliability and support.

I think there is a middle ground between supporting something and preventing you from attempting it. I don't care that meson doesn't work flawlessly with all of the compilers I listed above, but I do care that it doesn't work at all. I'm not aware of any other build system that doesn't let you specify an arbitrary compiler command.

jkbbwr commented 5 years ago

Why not a custom-compiler.txt like we have crossfiles.

dcbaker commented 5 years ago

Because it's rarely that simple. a lot of "posix" compilers actually try to emulate the GCC from whenever they were released with varying levels of success. What likely would work is to write some kind of a PosixCCompilerMixin class that you could use to trivially implement most of the boilerplate and the override as necessary. You'd still need to handle the detection in environment.py, and deal with the quirks of said compilers, which is not as trivial as you might expect, I know, I've turned on a few compilers in meson.

davidgiven commented 5 years ago

I've just run into this myself --- I was wanting to use sdcc (which is natively very non-Posix, but I'm perfectly willing to write wrapper scripts to adapt it. I was hoping to use meson for this, but if it hard codes support for certain compilers I can't.

jpakkane commented 5 years ago

There is a better way, namely adding the support for the given compiler toolchain to Meson itself. This means that everyone can use it. It's not that difficult and we even have docs for that. We would love to have sdcc support in master.

davidgiven commented 5 years ago

That's not a short term solution, though --- it requires me to do the work and then wait O(months) for the change to roll out to all the various software distributions (my Debian version is 0.49.2, which is about four months old). I could ask my users to sideload the build tool, but I've tried that in the past and it just adds enough complexity to the build process that they tend to prefer not to use my package.

averms commented 2 years ago

Not really related but fun fact: CMake supports TinyCC but the dependency resolution is broken. Editing an included header won't rebuild the source file that included that header.

illiliti commented 2 years ago

FYI: muon supports generic C compiler.

XVilka commented 1 year ago

For everyone caring about TinyCC (tcc) support (https://github.com/mesonbuild/meson/pull/8248), they seem to be closer to start crafting releases and recently bumped the version: https://github.com/TinyCC/tinycc/commit/086870addd9599ef74bed8e81ebb353da7836709

thesamesam commented 10 months ago

That's not a short term solution, though --- it requires me to do the work and then wait O(months) for the change to roll out to all the various software distributions (my Debian version is 0.49.2, which is about four months old). I could ask my users to sideload the build tool, but I've tried that in the past and it just adds enough complexity to the build process that they tend to prefer not to use my package.

If you'd done it when you first wrote this comment...

Anyway, I sympathise with "just let me try anyway, even if it may not work" for some barebones set of options specified in POSIX for c99 and friends. We spoof no for any compiler tests (as we don't know what the behaviour is beyond POSIX) and we only pass options we know will work.

As for whether Meson should have a --force or --please-let-me-try-the-unknown-compiler, I dunno. Not sure if that will be of much value once/if the above is implemented. It could be useful in the meantime but it's not very fitting with Meson's philosophy.

fluffeon commented 3 months ago

it's not very fitting with Meson's philosophy.

Which is..??