0.51.0: cpp_std setting not being applied #5590

phillipjohnston · 2019-07-01T23:56:19Z

This is tested with 0.51.0 and master @ commit 54b1c43277d16dcef2d8acc98d131ab9232d2fac.

I have a project which is specifying c_std and cpp_std:

project('libc',
	['c', 'cpp'],
	default_options : ['c_std=c11','cpp_std=c++17'])

I can see the C standard being applied in build.ninja:

build src/e88f707@@c@sta/crt__Exit.c.o: c_COMPILER ../src/crt/_Exit.c
 DEPFILE = src/e88f707@@c@sta/crt__Exit.c.o.d
 ARGS = -Isrc/e88f707@@c@sta -Isrc/ -I../src -I../include -I../src/gdtoa/include -I../arch/x86_64/include -Xclang -fcolor-diagnostics -pipe -Wall -Winvalid-pch -std=c11 -g -isystem ../printf -isystem ../src/gdtoa/include -isystem ../openlibm/src -isystem ../openlibm/include -isystem ../include -fno-builtin -nodefaultlibs -fno-stack-protector -DNO_ERRNO -DIFNAN_CHECK -DGDTOA_NO_ASSERT -DNO_FENV_H -Wno-reserved-id-macro -nostdinc

Build I don't see the C++ standard being set:

build printf_test@exe/printf_test_test_suite.cpp.o: cpp_COMPILER_FOR_BUILD ../printf/test/test_suite.cpp
 DEPFILE = printf_test@exe/printf_test_test_suite.cpp.o.d
 ARGS = -Iprintf_test@exe -I. -I.. -I../printf/test -Xclang -fcolor-diagnostics -pipe -Wall -Winvalid-pch -Wnon-virtual-dtor -g -Wno-format -Wno-format-invalid-specifier -Wno-old-style-cast -Wno-missing-prototypes

And the incorrect standard is further reflected by the failure to recognize the noexcept keyword:

[1/2] Compiling C++ object 'printf_test@exe/printf_test_test_suite.cpp.o'.
FAILED: printf_test@exe/printf_test_test_suite.cpp.o
c++ -Iprintf_test@exe -I. -I.. -I../printf/test -Xclang -fcolor-diagnostics -pipe -Wno-format -Wno-format-invalid-specifier -Wno-old-style-cast -Wno-missing-prototypes -MD -MQ 'printf_test@exe/printf_test_test_suite.cpp.o' -MF 'printf_test@exe/printf_test_test_suite.cpp.o.d' -o 'printf_test@exe/printf_test_test_suite.cpp.o' -c ../printf/test/test_suite.cpp
In file included from ../printf/test/test_suite.cpp:31:
../printf/test/catch.hpp:420:63: error: expected ';' at end of declaration list
        SourceLineInfo( char const* _file, std::size_t _line ) noexcept
                                                              ^
../printf/test/catch.hpp:427:43: error: expected ';' at end of declaration list
        SourceLineInfo( SourceLineInfo&& )              noexcept = default;

The target is quite simple:

printf_tests = executable('printf_test',
	sources: ['printf/test/test_suite.cpp'],
	cpp_args: ['-Wno-format', '-Wno-format-invalid-specifier', '-Wno-old-style-cast', '-Wno-missing-prototypes'],
	include_directories: [include_directories('printf/test')],
	native: true
)

This happens with both clang and GCC.

The text was updated successfully, but these errors were encountered:

phillipjohnston · 2019-07-01T23:57:32Z

Meson itself is picking them up correctly:

Compiler options (for host machine):
  Option        Current Value Possible Values                                         Description
  ------        ------------- ---------------                                         -----------
  c_args        []                                                                    Extra arguments passed to the C compiler
  c_link_args   []                                                                    Extra arguments passed to the C linker
  c_std         c11           [none, c89, c99, c11, c17, gnu89, gnu99, gnu11, gnu17]  C language standard to use
  cpp_args      []                                                                    Extra arguments passed to the C++ compiler
  cpp_eh        default       [none, default, a, s, sc]                               C++ exception handling type.
  cpp_link_args []                                                                    Extra arguments passed to the C++ linker
  cpp_std       c++17         [none, c++98, c++03, c++11, c++14, c++17, c++1z, c++2a, C++ language standard to use
                               gnu++11, gnu++14, gnu++17, gnu++1z, gnu++2a]

phillipjohnston · 2019-07-02T00:04:24Z

Possibly relates to #5495?

scivision · 2019-07-02T07:12:11Z

Does #5560 fix it? Are you using clang?

phillipjohnston · 2019-07-02T13:10:03Z

Will check shortly. I see this with clang and gcc. (mentioned at the bottom of the main post)

phillipjohnston · 2019-07-02T13:46:13Z

@scivision that does not fix the problem. My builds still fail and no C++ standard FLAG is present.

c++ -Iprintf_test@exe -I. -I.. -I../printf/test -Xclang -fcolor-diagnostics -pipe -Wall -Winvalid-pch -Wnon-virtual-dtor -g -Wno-format -Wno-format-invalid-specifier -Wno-old-style-cast -Wno-missing-prototypes -MD -MQ 'printf_test@exe/printf_test_test_suite.cpp.o' -MF 'printf_test@exe/printf_test_test_suite.cpp.o.d' -o 'printf_test@exe/printf_test_test_suite.cpp.o' -c ../printf/test/test_suite.cpp
In file included from ../printf/test/test_suite.cpp:31:
../printf/test/catch.hpp:420:63: error: expected ';' at end of declaration list
        SourceLineInfo( char const* _file, std::size_t _line ) noexcept
                                                              ^
../printf/test/catch.hpp:427:43: error: expected ';' at end of declaration list
        SourceLineInfo( SourceLineInfo&& )              noexcept = default;

phillipjohnston · 2019-07-02T13:48:02Z

Also, just tested: doesn't matter what std version I pick, none of the settings are applied for C++.

jpakkane · 2019-07-02T15:22:49Z

Managed to replicate this. The fix wlll be in 0.51.1.

jpakkane · 2019-07-02T16:52:08Z

@Ericson2314 this is actually quite complicated. The reason for this is that native: true causes the target to be tagged for build and then it picks up the wrong settings. In native compilation there are both build and host and they have different contents, at least for compiler options.

Trying to make the dicts in PerMachine to be the same breaks as well as ignoring native: true when building natively.

jpakkane · 2019-07-02T16:54:03Z

The unit test change is simple:

diff --git a/run_unittests.py b/run_unittests.py
index 90e5c9d8..a1e56b67 100755
--- a/run_unittests.py
+++ b/run_unittests.py
@@ -5242,7 +5242,9 @@ endian = 'little'
         testdir = os.path.join(self.unit_test_dir, '50 std remains')
         self.init(testdir)
         compdb = self.get_compdb()
+        self.assertEqual(len(compdb), 2)
         self.assertRegex(compdb[0]['command'], '-std=c99')
+        self.assertRegex(compdb[1]['command'], '-std=c99')
         self.build()
 
     def test_identity_cross(self):
diff --git a/test cases/unit/50 std remains/meson.build b/test cases/unit/50 std remains/meson.build
index ac6f9e24..51ae906e 100644
--- a/test cases/unit/50 std remains/meson.build        
+++ b/test cases/unit/50 std remains/meson.build        
@@ -1,2 +1,10 @@
 project('std_remains', 'c', default_options: ['c_std=c99'])
+
 executable('prog', 'prog.c')
+
+# Check that native: true does not affect the use of c_std in
+# non-cross builds
+
+if not meson.is_cross_build()  
+  executable('prog2', 'prog.c', native: true)

Making it actually work is trickier.

Ericson2314 · 2019-07-02T17:21:31Z

@jpakkane the current behavior is what I expect. The build.c_std vs c_std distinction is supposed to be the same so native and cross builds behave the same. The Ux logic is if you don't care about cross, then you wouldn't bother with native: true (that's why we removed my warning), and then you shouldn't notice any breakage, but if you do care about cross, then you should be careful with your native: true and build.c_std.

CC @dcbaker

jpakkane · 2019-07-02T17:27:27Z

If you do this:

project('xxx', 'c', default_options: ['c_std=c99'])
executable('foo', 'foo.c', native: true)

Then it must use -std=c99 to build the target. No ifs, buts or maybes. There is not even any option to set the standard version for this case, because build. options are not exposed when not cross compiling. Not doing that is counterintuitive and unexpected and will bury us in a stream of bug reports.

It does not matter so much how this is solved (like maybe make c_std mirror the host setting when native compiling) but this has to work.

Ericson2314 · 2019-07-02T17:34:03Z

@jpakkane Well that is why I originally did both build. and host. prefixes, with the unprefixed options affecting both build and host. You were worried about too many options and @dcbaker thought just build. and unprefixed is fine, so we went with that instead.

There is not even any option to set the standard version for this case, because build. options are not exposed when not cross compiling.

That is not true last I checked? The build.* options are always exposed.

jpakkane · 2019-07-02T17:49:25Z

That is not true last I checked? The build.* options are always exposed.

So they are. They really should not be, though. They clutter complicate things a lot for most people who don't cross build. They should only be shown when cross building. The output of meson configure has gotten almost unreadable with so many options.

But taking things one by one. If one sets default_options: ['c_std=c99', 'build.c_std=c99'] then it does work. @phillipjohnston is that a suitable fix and UI experience for you?

Having build. options always there makes things brittle for subproject usage. Suppose you have a project that builds a tool to generate sources and requires, say, c11 and sets build.c_std in its default options. Thus far everything works but if it is then used as a subproject (native building, not cross) and the master project has set c_std but not build.c_std, then things will break and the cause of that is not at all obvious.

phillipjohnston · 2019-07-02T18:03:10Z

@jpakkane, honestly, I'd rather stick with 0.50.1 than use that workaround. My main reason is this used to work as expected. Were I to upgrade, and were that to be the recommended solution moving forward, I would simply go back to manually managing standard flags in my project and not use the built-in meson options.

I thought your initial statement hit the nail on the head:

If you do this: [...] Then it must use -std=c99 to build the target. No ifs, buts or maybes. [...] Not doing that is counterintuitive and unexpected and will bury us in a stream of bug reports.

Adding build.c_std=c99 remains a counterintuitive and unexpected approach. The option name is not obvious. There's nothing in the name build.c_std that communicates to me "oh hey this is for the native build and that other one is for cross".

I also share your concern about subprojects. I have multiple projects that can be used standalone or as subprojects (such as this one, which is a libc implementation).

The reason I found this issue was that I started from a barebones system and walked through my project setup instructions to validate them - and suddenly I started getting strange build failures that didn't make sense and weren't reproducible on my main machine (which was still on 0.50.1). I've been using meson heavily for a year and a half, and here we are talking about the failures. So I don't expect people consuming my library to get that right if they're not meson experts.

phillipjohnston · 2019-07-02T18:10:25Z

My expectation is that the standard version specified for a project applies to everything if it's the default in my project.

I'm sure someone can come up with a great reason for needing different standards applied for cross/native builds. But I'm not one of them - and I'm pretty much always cross-compiling since I work on embedded systems.

jpakkane · 2019-07-02T18:15:33Z

For cross compilation the reason for the different values is simple: suppose you build a codegen tool that uses C++17 but your deployment target only has C++11 (or even 98). The problem in this particular case is that it causes confusion even when only native compiling.

phillipjohnston · 2019-07-02T18:17:27Z

Like I said, I'm sure there are good reasons :).

Your second point is correct: this error came up and I didn't have a cross configuration applied.

jpakkane · 2019-07-02T18:28:46Z

For cross compilation projects specifying both c_std and build.c_std makes sense and is expected. You set the default values once and then don't have to think about it any more. It adds a bit of boilerplate, sure, but also enables the functionality mentioned above.

But what I'm concerned with is that this makes things more tricky and unexpected for the majority of people who never cross compile. Having a build.c_std that seemingly does nothing is perplexing.

phillipjohnston · 2019-07-02T18:34:05Z

If that's how it is as the project marches on - I'll adapt. If that makes sense for supporting the largest number of use cases, great.

The thing that confuses me is "it's expected". Because it's not "expected" based on the sudden breakage of previously working projects, the contents of the 0.51.0 release notes, nor the documentation.

jpakkane · 2019-07-02T18:40:23Z

It is mentioned, but perhaps not as explicitly as it could have been...

phillipjohnston · 2019-07-02T18:43:00Z

Well, now I feel like a jerk because I even re-read the release notes to make sure I didn't miss anything. That's what I get :).

phillipjohnston · 2019-07-02T18:45:25Z

So to summarize my understanding after the discussion:

I deal with the way it is for cross-builds moving forward
Something needs to be figured out for targets marked native: true when not cross-compiling
I'll update some documentation to help clarify the points that confused me

phillipjohnston · 2019-07-02T18:51:29Z

Well, here's what I changed to:

project('Embedded Artistry libc',
	['c', 'cpp'],
	default_options : [
		# build.* options affect native: true targets when cross-compiling
		'c_std=c11', 'build.c_std=c11',
		'cpp_std=c++17', 'build.cpp_std=c++17',
	])

And then I get a warning:

WARNING: Unknown options: "build.c_std, build.cpp_std"

But the build still succeeds even with that warning.

jpakkane · 2019-07-02T18:54:10Z

I tested and got the same warning, but meson configure says that it has been properly set to c99.

Ericson2314 · 2019-07-02T19:24:53Z

@jpakkane I don't quite understand your subproject example. How default options with subprojects normally work? Why is the cross stuff special?

@phillipjohnston I apologize for not writing a louder "this is a breaking change" changelog entry. You might want to change your comment to:

		# `build.*` options affect `native: true targets`
		# plain options affect `native: false` targets.

because there is no cross-specific behavior. The whole point of the build. change affecting native builds is knowing which targets get which args, without knowing whether it's a native or cross build. In other words, it's about making the meson.build file more predictable regardless what the end user does with it. I don't expect everyone to love this build. change, but I want to at least make clear what it's motivation is.

Ericson2314 · 2019-07-18T16:47:15Z

Build definitions in files (flags for for-host and for-build targets etc) remain just as they are now. It's just that the external options you can set from the outside are not duplicated. There are only one set of those.

Are you saying that they can be separately varied internally, but CLI flags and env vars initialize them both in lock step in native builds?

Ericson2314 · 2019-07-18T16:51:22Z

hen the project call is first evaluated it is impossible to know whether the master project will use build. options or not or whether they come from a subproject.

Right now, subprojects only influence the master project with the global args functions, right? I'm suspicious of those two. Really anything that is global is highly non-compositional and liable to have confusing interactions.

jpakkane · 2019-07-18T18:24:27Z

Global might not be best of design ideas, but in my defence it was created before subprojects were invented.

That being said you can only add global arguments in the master project before any subproject is invoked. Trying to set them from subprojects or from the master project after a subproject call aborts immediately with a hard error.

Ericson2314 · 2019-07-18T22:14:53Z

@jpakkane Sounds good, I don't mean to accuse you of wanting all of the status quo :) Glad to learn that mutating the options in those other places is banned too!

byron-hawkins · 2021-04-21T11:43:53Z

After losing most of a day trying to figure out some very strange problems with type deduction, it finally became evident that the cpp_std is totally ignored in default_options, even with no other relevant options such as native or anything like it.

project('edfst', ['cpp'],                       
    default_options : ['cpp_std=c++17', 'warning_level=3'],
    version : '0.1'      
)

The workaround is simple:

add_project_arguments('-Dcpp_std=c++17', language : 'cpp')

For me there is no question: this is a bug in meson.

dcbaker · 2021-04-21T17:41:47Z

What version are you running? I can run exactly that code in meson 0.57.1 and it's setting -std=c++17 in my ninja.build files.

scivision · 2021-04-21T20:02:34Z

also important to know what compiler this is being experienced with

byron-hawkins · 2021-04-21T20:07:58Z

I have 0.55.3 via dnf in Fedora 32. It was telling me on the command line that cpp_std = none [ default = c++17 ], which I misinterpreted to mean "I see that there is no cpp_std set, so I'm using your default c++17".

After an epic chase-my-own-tail over a mountain of type deduction errors, I finally discovered what that meson output really means. So, why was cpp_std = none here when I didn't ask for that on the command line? I can't even guess...

byron-hawkins · 2021-04-21T20:11:28Z

The Meson build system
Version: 0.55.3
Source dir: /home/xxxx/cpp
Build dir: /work/xxxx/bin/cpp/release
Build type: native build
Project name: edfst
Project version: 0.1
C++ compiler for the host machine: c++ (gcc 10.2.1 "c++ (GCC) 10.2.1 20201125 (Red Hat 10.2.1-9)")
C++ linker for the host machine: c++ ld.bfd 2.34-6
Host machine cpu family: x86_64
Host machine cpu: x86_64

Found ninja-1.10.1.git at /work/lib/ninja/ninja

Why is it a native build? I never asked for such a thing.

dcbaker · 2021-04-21T21:51:34Z

"native" means "not a cross compiler", or in other words "host machine == build machine", let me pull 0.55.3 and see if I can reproduce with that. I did a huge refactor of how options are stored internally, so it may have been fixed in 0.56, but let me see.

dcbaker · 2021-04-21T22:07:37Z

I still can't reproduce this with 0.55.3, here's my meson.build for testing:

project('foo', 'cpp', default_options : ['cpp_std=c++17'])

executable('main', 'main.cpp')

and my main.cpp:

#include <iostream>
#include <optional>  // Unused, but force the use of C++17

int main() {
    std::cout << "Hello World!" << std::endl;
}

Here's my meson configure output:

  Compiler options    Current Value                                                                                                                                                                                                                                                                                         
  ----------------    -------------                                                                                                                                                                                                                                                                                         
  cpp_args            []                                                                                                                                                                                                                                                                                                    
  cpp_debugstl        false                                                                                                                                                                                                                                                                                                 
  cpp_eh              default                                                                                                                                                                                                                                                                                               
  cpp_link_args       []                                                                                                                                                                                                                                                                                                    
  cpp_rtti            true                                                                                                                                                                                                                                                                                                  
  cpp_std             c++17

and my ninja.build:

build main.p/main.cpp.o: cpp_COMPILER ../main.cpp                                                                                                                                                                                                                                                                         
  DEPFILE = main.p/main.cpp.o.d                                                                                                                                                                                                                                                                                           
  DEPFILE_UNQUOTED = main.p/main.cpp.o.d                                                                                                                                                                                                                                                                                      
  ARGS = -Imain.p -I. -I.. -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -std=c++17 -g                                                                                                                                                                                    
                                                                                                                                                                                                                                                                                                                          build main: cpp_LINKER main.p/main.cpp.o                                                                                                                                               
  LINK_ARGS = -Wl,--as-needed -Wl,--no-undefined

I'm not sure what's going on, can you provide more exact steps to reproduce?

byron-hawkins · 2021-04-21T22:22:15Z

What wsa your command line input to meson configure? Do you have any magic environment variables that might indicate c++17 in case it is not specified?

eli-schwartz · 2021-04-21T22:25:38Z

If you're using meson configure instead of meson setup then it sounds like you have an old build directory with saved options from a previous configuration. So those are getting used instead of the default_options ;) as the latter are only used when first setting the project up, not when editing options with configure.

byron-hawkins · 2021-04-21T22:42:22Z

I don't use "meson configure" or "meson setup", just "meson", and strictly after "rm -r *". There are no old options coming from an empty directory. Le jeu. 22 avr. 2021 à 00:25, Eli Schwartz ***@***.***> a écrit :

…

If you're using meson configure instead of meson setup then it sounds like you have an old build directory with saved options from a previous configuration. So those are getting used instead of the default_options. ;) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#5590 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAI2NKBIA5VKMGPPR6HOL2LTJ5GHHANCNFSM4H4W22XA> .

charlesnicholson · 2021-09-03T21:07:13Z

I'm experiencing the same phenomenon from a completely clean build. Meson 0.58.0:

project('<REDACTED>', ['c', 'cpp'],
    license: 'proprietary',
    version: '<REDACTED>',
    meson_version: '>=0.58.0',
    default_options: [
        'c_std=gnu11',
        'cpp_std=gnu++17',

Then, meson configure emits this:

build.c_std            none                     [none, c89, c99, c11,    C language standard to use
                                                 c17, c18, c2x, gnu89,
                                                 gnu99, gnu11,
                                                 gnu17, gnu18, gnu2x]
build.cpp_args         []                                                Extra arguments passed to the cpp compiler
build.cpp_eh           default                  [none, default, a, s,    C++ exception handling type.sc]
build.cpp_link_args    []                                                Extra arguments passed to the cpp linker
build.cpp_rtti         true                     [true, false]            Enable RTTI
build.cpp_std          none                     [none, c++98, c++03,     C++ language standard to use
                                                 c++11, c++14, c++17,
                                                 c++1z, c++2a, c++20,
                                                 gnu++11, gnu++14,
                                                 gnu++17, gnu++1z,
                                                 gnu++2a, gnu++20]

I'm cross-compiling and attempting to build C++ code on the host machine, but none of the version flags are being applied.

The suggested above workaround does not seem to help:

add_project_arguments('-Dcpp_std=gnu++17', language : 'cpp')

Meson simply appears to be broken.

charlesnicholson · 2021-09-03T21:16:07Z

Update:

The workaround does work (note the native: true).

add_project_arguments('--std=gnu++17', language: 'cpp', native: true)
add_project_arguments('--std=gnu11', language: 'c', native: true)

Note that this bug only appears in cross-compilation configurations.

dcbaker · 2021-09-04T16:00:22Z

@charlesnicholson, meson sets two standards, one for build machine targets, and one for host machine targets, the undecorated cpp_std=... is for host targets, and build.* is only for build targets. what you want is:

project(
    ...,
    default_options : ['cpp_std=c++17', 'build.cpp_std=c++17'],
)

charlesnicholson · 2021-09-04T16:12:05Z

Ah, thanks! Are these multiple standards documented anywhere? I don't see it in the places I'd expect:

https://mesonbuild.com/Cross-compilation.html#mixing-host-and-build-targets
https://mesonbuild.com/howtox.html#set-default-cc-language-version

And build is an unfortunate name for trying to do detailed google searches on, in the scope of a build system.

dcbaker · 2021-09-05T16:27:26Z

It's not super clearly called out, but it's on this page; https://mesonbuild.com/Builtin-options.html. they're called per-machine options

charlesnicholson · 2021-09-05T16:47:39Z

Meson has everything it needs to proactively detect this and push users in the right direction.

If a cross compilation is configured, and native (build) targets are used, and the user has per-machine options set for the host but not the build machine, that could be a warning that requires suppression or configuration parity. In this case, meson could say "Hey, you have the following option default values configured for host but not build: c_std ,cpp_std, disable this warning with XYZ or add build. equivalents."

This would be a vastly better experience than what currently exists.

dcbaker · 2021-09-06T14:50:12Z

@charlesnicholson, i agree, can you open a new issue for that?

charlesnicholson · 2021-09-06T15:13:31Z

Filed #9227

DarkArc · 2023-06-25T21:04:29Z

I still can't reproduce this with 0.55.3, here's my meson.build for testing:

project('foo', 'cpp', default_options : ['cpp_std=c++17'])

executable('main', 'main.cpp')

and my main.cpp:

#include <iostream>
#include <optional>  // Unused, but force the use of C++17

int main() {
    std::cout << "Hello World!" << std::endl;
}

That's a very unreliable way to test for C++ language level. Here's a trivial program (ref this table):

app.cpp

#include <iostream>

int main() {
  std::cout << __cplusplus << '\n';
  return 0;
}

meson.build:

project(
  'test-proj',
  'cpp',
  version : '0.1',
  default_options : [
    'warning_level=3',
    'cpp_std=c++20'
  ]
)

boost_dep = dependency('boost')

exe = executable(
  'test-proj',
  'app.cpp',
  dependencies : boost_dep
)

test('basic', exe)

$> meson --version
1.0.1
$> ./test-proj
201703 # C++ 17, not C++20

I tried Meson for the first time today, this has not been a great experience.

machitgarha · 2024-03-24T19:05:51Z

One workaround that worked for me is using override_options for all executable()s:

executable(
    # ...
    override_options: ['cpp_std=c++20']
)

BTW, cpp_std not working per-project is bad user experience, and should be fixed ASAP. C++ standard is one of the most basic things, IMHO.

phillipjohnston changed the title ~~cpp_std setting not being applied~~ 0.51.0: cpp_std setting not being applied Jul 2, 2019

phillipjohnston changed the title ~~0.51.0: cpp_std setting not being applied~~ 0.51.0: cpp_std setting not being applied for clang Jul 2, 2019

phillipjohnston changed the title ~~0.51.0: cpp_std setting not being applied for clang~~ 0.51.0: cpp_std setting not being applied Jul 2, 2019

scivision mentioned this issue Jul 2, 2019

Trying to set c_std to 18 and got an error #5539

Closed

jpakkane added this to the 0.51.1 milestone Jul 2, 2019

mikezackles mentioned this issue Jul 24, 2019

jar targets can't link against preexisting jars (e.g., android.jar) #5709

Open

TheQwertiest mentioned this issue Sep 30, 2019

No way to build subproject with different warning level? #5466

Closed

robbert-vdh mentioned this issue May 18, 2020

WARNING: Unknown options: "build.cpp_std" and "cpp_std" robbert-vdh/yabridge#16

Closed

lenary mentioned this issue Jun 23, 2020

Meson pain points tracking issue lowRISC/opentitan#1617

Closed

MaxKellermann mentioned this issue Jul 1, 2020

[gcc-mingw-w64-x86-64] [GenParseName.cxx] error: ‘string_view’ is not a member of ‘std’ MusicPlayerDaemon/MPD#890

Closed

charlesnicholson mentioned this issue Sep 6, 2021

Feature Request: Warn about build/host asymmetry in default options #9227

Open

0.51.0: cpp_std setting not being applied #5590

0.51.0: cpp_std setting not being applied #5590

Comments

phillipjohnston commented Jul 1, 2019 • edited Loading

phillipjohnston commented Jul 1, 2019

phillipjohnston commented Jul 2, 2019

scivision commented Jul 2, 2019

phillipjohnston commented Jul 2, 2019

phillipjohnston commented Jul 2, 2019

phillipjohnston commented Jul 2, 2019

jpakkane commented Jul 2, 2019

jpakkane commented Jul 2, 2019

jpakkane commented Jul 2, 2019

Ericson2314 commented Jul 2, 2019

jpakkane commented Jul 2, 2019

Ericson2314 commented Jul 2, 2019 • edited Loading

jpakkane commented Jul 2, 2019

phillipjohnston commented Jul 2, 2019 • edited Loading

phillipjohnston commented Jul 2, 2019

jpakkane commented Jul 2, 2019

phillipjohnston commented Jul 2, 2019

jpakkane commented Jul 2, 2019

phillipjohnston commented Jul 2, 2019 • edited Loading

jpakkane commented Jul 2, 2019

phillipjohnston commented Jul 2, 2019

phillipjohnston commented Jul 2, 2019 • edited Loading

phillipjohnston commented Jul 2, 2019 • edited Loading

jpakkane commented Jul 2, 2019

Ericson2314 commented Jul 2, 2019 • edited Loading

Ericson2314 commented Jul 18, 2019

Ericson2314 commented Jul 18, 2019

jpakkane commented Jul 18, 2019

Ericson2314 commented Jul 18, 2019 • edited Loading

byron-hawkins commented Apr 21, 2021

dcbaker commented Apr 21, 2021

scivision commented Apr 21, 2021

byron-hawkins commented Apr 21, 2021

byron-hawkins commented Apr 21, 2021

dcbaker commented Apr 21, 2021 • edited Loading

dcbaker commented Apr 21, 2021

byron-hawkins commented Apr 21, 2021

eli-schwartz commented Apr 21, 2021 • edited Loading

byron-hawkins commented Apr 21, 2021 via email

charlesnicholson commented Sep 3, 2021

charlesnicholson commented Sep 3, 2021

dcbaker commented Sep 4, 2021

charlesnicholson commented Sep 4, 2021

dcbaker commented Sep 5, 2021

charlesnicholson commented Sep 5, 2021

dcbaker commented Sep 6, 2021

charlesnicholson commented Sep 6, 2021

DarkArc commented Jun 25, 2023 • edited Loading

machitgarha commented Mar 24, 2024

phillipjohnston commented Jul 1, 2019 •

edited

Loading

Ericson2314 commented Jul 2, 2019 •

edited

Loading

phillipjohnston commented Jul 2, 2019 •

edited

Loading

phillipjohnston commented Jul 2, 2019 •

edited

Loading

phillipjohnston commented Jul 2, 2019 •

edited

Loading

phillipjohnston commented Jul 2, 2019 •

edited

Loading

Ericson2314 commented Jul 2, 2019 •

edited

Loading

Ericson2314 commented Jul 18, 2019 •

edited

Loading

dcbaker commented Apr 21, 2021 •

edited

Loading

eli-schwartz commented Apr 21, 2021 •

edited

Loading

DarkArc commented Jun 25, 2023 •

edited

Loading