CFLAGS for Visual Studio

[6e9e202e-bdf1-4310-b38f-78ed4a197708]

BPO	24973
Nosy	@pfmoore, @tjguk, @bitdancer, @zware, @zooba
Files	addcflags3_5.patch: Patch for 3.5 addcflags2_7.patch: Patch for 2.7

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields: ```python assignee = None closed_at = None created_at = labels = ['type-feature', 'OS-windows', 'build'] title = 'CFLAGS for Visual Studio' updated_at = user = 'https://bugs.python.org/christopherhogan' ``` bugs.python.org fields: ```python activity = actor = 'steve.dower' assignee = 'none' closed = False closed_date = None closer = None components = ['Build', 'Windows'] creation = creator = 'christopher.hogan' dependencies = [] files = ['40308', '40309'] hgrepos = [] issue_num = 24973 keywords = ['patch'] message_count = 6.0 messages = ['249427', '249429', '249430', '249433', '249453', '249491'] nosy_count = 6.0 nosy_names = ['paul.moore', 'tim.golden', 'r.david.murray', 'zach.ware', 'steve.dower', 'christopher.hogan'] pr_nums = [] priority = 'normal' resolution = None stage = 'patch review' status = 'open' superseder = None type = 'enhancement' url = 'https://bugs.python.org/issue24973' versions = ['Python 2.7', 'Python 3.5', 'Python 3.6'] ```

[6e9e202e-bdf1-4310-b38f-78ed4a197708]

This Visual Studio project change appends to the compiler flags any values in the CFLAGS environment variable.

[zooba]

The patch should just set it once in pyproject.props, not in each project.

Why is this necessary? Is there an option we should be exposing in some other way?

[zware]

The real driver for this is having a nice easy way to pass '/fp:strict' to icl.exe (ICC's cl.exe). There may be other things that would be nice to be able to pass easily for customization.

[zooba]

I assume you're referring to bpo-24974? The default (for MSVC) is /fp:precise, which should allow fenv_access, but maybe ICL uses /fp:fast by default for the extra speed?

It's not a safe 3.5 change now, but compiling with /fp:fast by default and using #pragma float_control(precise, push)/#pragma float_control(pop) around that section may be an option for 3.6, if the benchmarks show some value in it. Either way, the pragma is probably the better way to require particular behaviour for that section of code, rather than changing a global option.

I'm not totally opposed to allowing an extra option for setting flags when building, but there'll almost always be a better fix.

[zware]

Steve Dower wrote:

I assume you're referring to bpo-24974?

It's somewhat related, yes, but I didn't intend for the two issues to be tightly coupled. Both should be dealt with independently of each other.

The default (for MSVC) is /fp:precise, which should allow fenv_access, but maybe ICL uses /fp:fast by default for the extra speed?

I believe that's correct.

I'm not totally opposed to allowing an extra option for setting flags when building, but there'll almost always be a better fix.

That's probably true. I will say though that it's really hard to pass build options to a buildbot. I have yet to find a way to pass properties with no spaces in the value, for example, "/p:IncludeSSL=false" (if you know of a way to pass that to MSBuild correctly through Tools/buildbot/build.bat called by 2.7's subprocess module, I'm all ears :)). To continue the floating point example, the only method (other than this) I've found to pass in a different model is to hack in another property to check and set FloatingPointModel in the ClCompile ItemDefinitionGroup, which has the same problem as the 'IncludeSSL' issue I mentioned above. With a nice simple 'CFLAGS' property that doesn't care about extra spaces in the value, it becomes possible to pass '/fp:strict' to a buildbot easily.

Also, ICC has *a lot* of extra command line options that may be interesting to pass in, but I'm quite sure we don't want to hack any of them into the project files.

By the way, '/fp:strict' is just what we've been manually defaulting to for ICC builds since before bpo-21167 was committed, which made '/fp:strict' unnecessary.

[zooba]

All environment variables are promoted to MSBuild properties, so if you "set IncludeSSL=false" before building then it will show up (which is exactly how the proposed patch is getting CFLAGS in).

Unfortunately, batch file argument parsing is pretty horrid. I'd be happy to move to PowerShell based scripts, but that'll be asking a lot of some people, and probably isn't feasible for the existing buildbots.

Another concern about using CFLAGS is people ending up with broken builds because they had something else set in there - mostly because it's near impossible to diagnose remotely.

If we call it PY_CFLAGS\< move it to pyproject.props, and require "$(BuildForRelease) != 'true'", then I'm fine with it. (The last condition ensures that official release builds via Tools\msi\buildrelease.bat will never be affected, and gives a fairly strong indication not to rely on implicit settings like this. Defaults that we need for actual releases should be integrated properly.)