fix and improvement for vcxproj generation

[nono303]

Hi @wbhart, This PR with some fix and improvement. each changes detailed in commit some might be discussed ^^

[BrianGladman]

I am sorry but this is a huge set of changes to a stable build system. You really should have consulted me before doing this sort of work as there is no prospect of a quick or easy merge because of the significant number of changes that you are proposing in how the build works and where the outputs are located. The latter in particular will impact on all the other projects (mpfr, msieve, gmpy2, gmp-ecm, ...), all of which expect to find MPIR outputs where they are currently placed.

[nono303]

Thx for your reactivity and I fully understand your answer! I just push this PR as I have do these fix (and breaking changes^^) for my build process (https://github.com/nono303/win-build-scripts) Effectively, modification proposed are maybe finalizing the build process in a more standard structure (in my point of view) but might have huge impact on other dependents You can close the PR, I’ll continue on my fork and will merge on your update :)

[BrianGladman]

Thanks for your understanding. I did notice some areas where you have proposed changes that improve the build without changing what it does. For example, changes that apply to the VS 22 details in version_info.py, and I will look into updating these. If there are changes of this kind that would make things easier for you, I would certainly be happy to take a look at them. But running from a fork is the only realistic way of working once the locations of tools and inputs and outputs from the build need to change. It is good to know that the build is useful at least as a basis for what you are doing.

[nono303]

Hi @BrianGladman, Don't hesitate to ask me if needed on some part of my change would be interesting to merge on your repository. I've extracted interesting changes from https://github.com/BrianGladman/mpir/pull/26.patch here >> nono303-extract.patch I Agree that it might be easier to integrate than a PR ^^ Note that only changes in postbuild.bat and targetsuf definition in _msvc_project.py are breaking changes.

Also have question about my merge on /mpn/x86_64w/*.asm with https://github.com/wbhart/mpir/commit/b3367eb13eca95b3a204beaca5281a2c3b4c66a6 (cf. https://github.com/BrianGladman/mpir/pull/26/commits/1f1cd1031b7238a8d80faaffca36d1ebd1409eb4); It seems that some of your fix are not back-ported and vice-versa. do you know what is the reference for these files : yours or wbhart ones ?

[BrianGladman]

Thank you for your effort to provide material that would be of benefit in the MPIR Windows build system.

I have to admit that I am having difficulty reacting to this because you are offering me the code with no explanation of rationale for the changes that you have made. And without a rationale for each proposed change it is impossible for me to judge whether there is benefit in incorporating it. And I really don't have the time to work back from your code changes to try to understand your rationale for making them. This is absolutely the wrong way round! i.e. (1) decide on a needed feature, (2) develop a rationale for it, (3) propose it and get it accepted as beneficial, (4) implement it.

There has been a long term issue in the confusion between the public Visual Studio version number (now 22) and the internal version number (now 17). I used to use the the internal version number but because this caused so much confusion among users I switched to the public version number instead. Note that the msvc and msvc_long defines are the MSVC compiler versions in use, which is 19.x for VS 2022.

On your question about whether it is my repository or the wbhart repository that is the reference. For Windows builds using Visual Studio it is this repository, for all other builds (including Windows builds using GCC) it is the wbhart repository. For all changes to code in the mpir\mpn\x86w and mpir\mpn\x86_64w directories it is this repository that is the reference.