Remove some unused files

[isuruf]

Why? We use MPIR for windows in conda-forge.

[skirpichev]

Oops. @isuruf, thank you for catching this. Then, this support should be tested.

Just curious, why you did this? See e.g. https://trac.sagemath.org/ticket/32549

[isuruf]

GMP does not have long long (int64_t) support on windows and no Visual Studio support. That's why we've been using MPIR on windows. We use GMP on Unix-like OSes, but on windows we are stuck with MPIR.

[casevh]

I will respond tomorrow. Dealing with major Internet outage in our area.

On Tue, Feb 14, 2023, 7:06 PM Isuru Fernando @.***> wrote:

GMP does not have long long (int64_t) support on windows and no Visual Studio support. That's why we've been using MPIR on windows. We use GMP on Unix-like OSes, but on windows we are stuck with MPIR.

— Reply to this email directly, view it on GitHub https://github.com/aleaxit/gmpy/pull/380#issuecomment-1430687107, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMR23ZR2MPR6DUSEOHCY33WXRB3VANCNFSM6AAAAAAU4JTT3U . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[skirpichev]

@isuruf, Are you sure about the first point? GMP 5.1.0 announce says "The performance under M$ Windows' 64-bit ABI has been greatly improved thanks to complete assembly support."

no Visual Studio support

Have you considered building with mingw & msys? Could you verify that the current master is ok for you (i.e. for VC builds)? As I said above, it wasn't tested, unfortunately.

The problem is that MPIR has not been updated upstream (v3 claims to support GMP v6.0.0) long time.

[casevh]

We used to support MPIR without the need to use the --gmp-compat (sp?) option. That was phased out a while ago. However, some references to MPIR remained. Sergey removed the remaining references to MPIR as part of a long-overdue cleanup.

gmpy2 should still be able to utilize MPIR when compiled with --gmp-compat. If you find errors, I will fix them if possible.

However, I have concerns with MPIR that have convinced me to distribute GMP/MPFR/MPC libraries that are compiled with mingw64 (and related tools).

1) GCC is required for the --enable-fat option for GMP. I want GMP to automatically recognize and use the optimal assembly code. This is the primary motivation for using GCC.

2) MPIR does not support mpz_powm_sec. I consider mpz_powm_sec to be an important function that should be fully supported by a current, well-maintained GMP-compatible library. This is the primary motivation for using GMP instead of MPIR. (Support for mpz_pown_sec was added in gmpy2 2.1.3 and is unrelated to Sergey's PR.)

I plan to release gmpy2 2.2 with a patched version of GMP that uses a 64-bit mp_bitcnt_t.

With some effort, Visual Studio can compile Cython extensions using the provided GMP/MPFR/MPC libraries. I plan to simplify this use case, too.

I appreciate all the effort that is required to build and maintain an ecosystem of Python extensions. MPIR is appropriate for your ecosystem. I have no plans to prevent MPIR from being used. I am just focusing my time on the priorities that are important to me.

Regards, Case

[skirpichev]

The correct option is --enable-gmpcompat.

But I've reverted the MPIR-related part.

[casevh]

The posix64 directory contains an incomplete implementation of the APRCL primality test. I want to get it working.

I would like to leave this PR on-hold for now.

[skirpichev]

Does it make sense to keep something else? If not, I'll just revert posix64/* stuff too.

[skirpichev]

Ok, src/posix64/* was reverted too and pr was rebased.

[skirpichev]

@casevh, could you decide on this pr? This removes now just windows_build.txt and src/mpz_pylong.c.

[skirpichev]

Ok, I guess your opinion is that this stuff should be kept.