Skip to content
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

Merged
merged 1 commit into from
Dec 4, 2017
Merged

Make C++ warnings errors (i.e. -Werror) in posix.mak #7387

merged 1 commit into from
Dec 4, 2017

Conversation

JinShil
Copy link
Contributor

@JinShil JinShil commented Dec 2, 2017

Attempt at shepherding #7358 across the finish line.

@dlang-bot
Copy link
Contributor

Thanks for your pull request, @JinShil!

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

@jacob-carlborg
Copy link
Contributor

Aren't there any complains about the C++ files in the backend are using the .c extension?

@ibuclaw
Copy link
Member

ibuclaw commented Dec 2, 2017

Aren't there any complains about the C++ files in the backend are using the .c extension?

That's what the testsuite will tell us.

@ibuclaw
Copy link
Member

ibuclaw commented Dec 2, 2017

@JinShil
Copy link
Contributor Author

JinShil commented Dec 2, 2017

@JinShil - Forgetting some patches?

Thanks!

Copy link
Member

@ibuclaw ibuclaw left a 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.

@WalterBright WalterBright merged commit b31c759 into dlang:master Dec 4, 2017
@MartinNowak
Copy link
Member

MartinNowak commented Dec 12, 2017

This has broken the release builds with an older clang on OSX.

Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin12.2.0
Thread model: posix

@MartinNowak
Copy link
Member

See #7430

@JinShil
Copy link
Contributor Author

JinShil commented Dec 12, 2017

This has broken the release builds with an older clang on OSX.

Why wasn't it caught by the auto-tester?

@MartinNowak
Copy link
Member

Because that is running a newer clang version, apparently the compiler was fixed to not be so picky.

@jacob-carlborg
Copy link
Contributor

Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin12.2.0
Thread model: posix

I suggest that the compiler is updated. Clang 5 and LLVM 3.4 is pretty old. Latest version of Xcode is 9.2.

@jacob-carlborg
Copy link
Contributor

This has broken the release builds with an older clang on OSX.

The same compiler that is running the tests should be building the releases. Ideally on the same computer.

@wilzbach
Copy link
Member

I suggest that the compiler is updated. Clang 5 and LLVM 3.4 is pretty old. Latest version of Xcode is 9.2.

Good luck!
We are working since February to upgrade the auto-tester, s.t. we can finally transition from ddmd -> dmd (see e.g. #7135 or #6562).

@jacob-carlborg
Copy link
Contributor

How is "ddmd -> dmd" related to upgrading Clang?

@wilzbach
Copy link
Member

How is "ddmd -> dmd" related to upgrading Clang?

It's just an example on how difficult it is to upgrade things on auto-tester.

@jacob-carlborg
Copy link
Contributor

Ok. Is Brad the only one with access?

@braddr
Copy link
Member

braddr commented Dec 13, 2017

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)
Darwin 15.6.0, Apple LLVM version 8.0.0 (clang-800.0.42.1)
Darwin 16.7.0, Apple LLVM version 9.0.0 (clang-900.0.39.2)

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.

@jacob-carlborg
Copy link
Contributor

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.

Fair enough. Then it's also understandable why it might take longer, if only one person is responsible.

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.

I see. I would hope that upgrading just the compiler is simpler than upgrading the whole operating system.

@JinShil JinShil deleted the cpp_warnings branch December 29, 2017 12:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants