homepage

I would be very useful to have a `has_flag` method in `distutils.CCompiler` similar to `has_function`, allowing to check if the compiler supports certain flags.
Cmake has a `CHECK_CXX_COMPILER_FLAG` macro for that purpose, which checks if a simple C++ file compiles with the said flag.

I attached a patch for ccompiler.py adding the new `has_flag` method.

I've left a comment on Rietveld

New version of the patch using the context manager.

I understand that you're copying approach of has_function, but shouldn't you remove this temporary file at the end of the function? Perhaps using tempfile.NamedTemporaryFile would be a better solution (both in has_flag and has_function). Also import can be moved to the top level, since it's used in more than one method.

@minrk submitted http://bugs.python.org/file40933/0001-cleanup-temporary-files-in-ccompiler.has_function.patch
doing what you describe for `has_function`. 
I don't know much about the process to contribute to cpython. I would be glad to open a "PR" incorporating Min's commits too.

I guess it would make sense to depend on issue25544 and implement the has_flag with minrk's patch in mind. I guess his patch didn't get a second look because it didn't apply cleanly.
In any case, for implementing has_flag using current best practice is what I'd recommend.

A new version of the patch using `NamedTemporaryFile` instead a the regular fdopen.

Are you fine with the new state of the patch?

I'm largely fine with it, bar the in-function import. It would also be good if you could verify that no other temporary files are left after the function is run.
As I said earlier, issue 25544 should have priority and it should get a refreshed patch soon.
Donald, I'm assigning issue to you since you're maintaining this module.

Hey, any blocker to getting this in?

FYI, NamedTemporaryFile doesn't work well with Windows. There are a handful of issues about it.

Any chance to get this in for 3.6?

Sylvain, have you brought this feature request up on the Distutils mailing list? The PyPA there is responsible for packaging features. One big issue with adding new features to Distutils is the backwards-compatibility tradeoff: many third-party package authors want to support their distributions on multiple Python versions which is one of the reasons why we are generally very cautious about changing or even adding APIs to Distutils at this point in its life.
https://mail.python.org/mailman/listinfo/distutils-sig 

Thanks Ned. I posted a couple of messages on distutils-sig and got little attention.
I think that this feature is very important for detecting whether a compiler supports a certain flag like `-std=c++11` and provide a meaningful error when needed.
CMake has the same feature, implemented in a similar fashion (CHECK_CXX_COMPILER_FLAG).

"I posted a couple of messages on distutils-sig and got little attention."
OK, for future reference, the start of the discussion was here:
https://mail.python.org/pipermail/distutils-sig/2016-May/029010.html
It looks like the first item, the one relative to this issue, got lost in the discussion of the second item. I'm attempting to (re-)start the discussion there (my post may be awaiting moderation).

https://mail.python.org/pipermail/distutils-sig/2016-August/029469.html 

Distutils is now deprecated (see PEP 632) and all tagged issues are being closed. From now until removal, only release blocking issues will be considered for distutils.
If this issue does not relate to distutils, please remove the component and reopen it. If you believe it still requires a fix, most likely the issue should be re-reported at https://github.com/pypa/setuptools