-
-
Notifications
You must be signed in to change notification settings - Fork 636
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
Make C++ warnings errors (i.e. -Werror) in posix.mak #7387
Conversation
Thanks for your pull request, @JinShil! Bugzilla referencesYour PR doesn't reference any Bugzilla issue. If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog. |
Aren't there any complains about the C++ files in the backend are using the |
That's what the testsuite will tell us. |
@JinShil - Forgetting some patches? https://github.com/dlang/dmd/pull/7358/files#diff-9b5e2f2ac206ebe201f44f8e316514bcR4247 |
Thanks! |
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.
ok, but ping @WalterBright on backend stuff.
This has broken the release builds with an older clang on OSX.
|
See #7430 |
Why wasn't it caught by the auto-tester? |
Because that is running a newer clang version, apparently the compiler was fixed to not be so picky. |
I suggest that the compiler is updated. Clang 5 and LLVM 3.4 is pretty old. Latest version of Xcode is 9.2. |
The same compiler that is running the tests should be building the releases. Ideally on the same computer. |
How is "ddmd -> dmd" related to upgrading Clang? |
It's just an example on how difficult it is to upgrade things on auto-tester. |
Ok. Is Brad the only one with access? |
I'm the only one with access to most of the machines. They're typically behind firewalls and on networks I don't have liberty to give direct access to. The Feb to Now transition time for ddmd -> dmd can't be reasonably placed on me like that. Maybe a month of the total time can, but the rest, sorry, no. The rest was largely waiting for the build system and branches to be in sync enough that the changes to the auto-tester wouldn't break every build. I won't pull change just because they've been submitted. They kinda have to work too. As to the osx versions, there's three of them in the fleet, each with a different version. I'd be happy to upgrade the oldest ones if we're deprecating support for those altogether. The versions in place: Darwin 13.4.0, Apple LLVM version 6.0 (clang-600.0.57) (based on LLVM 3.5svn) The difficulty is that we've got a large set of platforms, several branches, and lots of project in flight and aligning them all correctly doesn't happen as fast as anyone would like. Another great example is upgrading the freebsd supported platform from 8.x to 10 and/or 11. I'd love to, except that the code base doesn't pass testing on them. I even setup the auto-tester to build and test master against those platforms. No one touched that project beyond a tiny bit of initial interest. |
Fair enough. Then it's also understandable why it might take longer, if only one person is responsible.
I see. I would hope that upgrading just the compiler is simpler than upgrading the whole operating system. |
Attempt at shepherding #7358 across the finish line.