Installation instructions without configure

[ThibautVerron]

Hello,

The INSTALL file specifies to run ./configure && make, even though there is no configure executable in the source tree.

I suspect that the installation instructions were not updated after issue #205 was fixed.

[wbhart]

The documentation is for the released version of MPIR, not the GitHub repo.

There are people who argue on both sides of the issue with regard to putting configure in the repo. However GitHub+Code review does argue strongly for not having it in the repo. I appreciate the difficulty, but a decision has been made on the issue and it is extremely unlikely to be revisited.

[ThibautVerron]

It was my understanding, based on what's written on the website, that the GitHub repo would be the only form of release in the future?

If that understanding is wrong, new tarballs (with configure) being available for milestone releases, then there is no issue whatsoever.

[wbhart]

There certainly won't be official releases. But it could be that we set up nightly tarballs or something. A lot depends on how the project is supported going forward.

But you are right. If we drop the tarballs altogether, it would make more sense to adjust the INSTALL for the tarball.

[dimpase]

There certainly won't be official releases

What exactly does this mean? Do you mean to say you are not going to make them yourself? Perhaps you can still delegate this... Can't we have a community official unofficial release? I definitely would like to see a release to update what we have in Sagemath.

[dimpase]

What is exactly the state of affairs now? Is there anything holding up a new release (I could volunteer to make one...)?

[wbhart]

If you know how to do it, go right ahead. But without an ongoing commitment from others, they won't happen by my hand.

[wbhart]

There's nothing specific holding up a release right now. The repo is in a good state. Please ensure .so numbering is changed and the documentation is updated CHANGES, Contributors, NEWS, etc.

[dimpase]

So you'd like it done the usual way, as a pull request?

[KevinHake]

I'm reading between the lines here, so anyone please correct me if I'm wrong. @dimpase - what hasn't been said directly: This project has a wealth of great code, and has had a lot of really talented people contributing, still does. It is long-running, so long that many of the great contributors have begun to move on, or moved on entirely. Some towards other projects, some towards retirement and different life priorities, some are no longer physically with us. @wbhart owns this repo, and for his own reasons is not going to be producing releases anymore. From my lurking and poking around in the last year or so, there is still active development, but more on a personal use and hobby maintenance level than a more organized effort to maintain a public library that some people might be used to elsewhere. Given that releases will not be coming from @wbhart, if new releases are to happen in the future, it will need to be in a fork maintained by someone else. Whether such a release can still carry the MPIR name would be up to @wbhart to decide, but the code is all GPL (I haven't looked too hard at the licensing since all my mpir projects are personal projects) and free to be used as such (in the same way MPIR is a fork of GMP). @dimpase - what is your motivation for creating a new official release? I did a bit of pruning and merging work bringing a number of @BrianGladman's fixes/refactors into sync with the main repo a few months ago (https://github.com/KevinHake/mpir), maybe it could be of use to you. If we have some of the same goals I wouldn't mind helping put together a release in my spare cycles.

[dimpase]

On Sun, Nov 4, 2018 at 9:39 PM KevinHake notifications@github.com wrote:

@dimpase https://github.com/dimpase - what is your motivation for creating a new official release?

For one, MPIR is the default integer arithmetic library in Sagemath. Naturally we do like being up to date in Sagemath, whereas currently we are shipping an MPIR version 3.0.0-644faf502c56f97d9accd301965fc57d6ec70868... (yep, 3.0.0 updated by some commits...)

Another CAS which uses MPIR is Macaulay2, which is very popular among commutative algebraists...

[KevinHake]

I am guessing Sagemath uses mpir for both Linux and Windows builds. @dimpase Do you build for Windows with Visual Studio, or with MinGW? The main branch here has recently removed the Visual Studio build files. @BrianGladman's repo has it all, but it is out of sync with the main branch, and also includes experimental/work-in-progress changes to master. Personally I like having the Windows and Linux stuff all in one place, and using the same stable code base, running tests etc which was my motivation for merging stuff together.

[dimpase]

Sage on Windows is built on Cygwin. Several packages of its need Posix fork, that's why.

[BrianGladman]

@KevinHake With respect to the work going on in my repository on the Visual Studio/MSVC build for MPIR, let me reassure you that nothing has changed with respect to its ongoing development. From the very moment MPIR was forked from GMP, there has only ever been one developer/maintainer of the native Windows Visual Studio/MSVC build system. The only prospective change being considered now is that of moving to separate distributions for the Linux/GCC and Windows/MSVC builds. The reason for this I believe is that, for each community, the perceived 'cost' of carrying the build files needed by the other community in 'their' distribution has become too large.

[GitMensch]

But it could be that we set up nightly tarballs or something.

Done with #276, I may find some time in the next month to add a nice README.md showing the current build status (and therefore link to the nightly tarballs), along with the "instruction" to use these and what needs to be done if you want to build from here. You find the nightly tarballs at https://ci.appveyor.com/project/wbhart/mpir (then choose whatever build you want, go to "artifacts" and grab your tarball).

The only prospective change being considered now is that of moving to separate distributions for the Linux/GCC and Windows/MSVC builds. The reason for this I believe is that, for each community, the perceived 'cost' of carrying the build files needed by the other community in 'their' distribution has become too large.

I'm still sure that the 'cost' of not being up-to-date without additional PR is much higher. If there's consensus for a "split" - why not creating an official "Windows" branch here that is up-to-date with everything and just additional contains the Windows build files? For the "their distributition has become too large part" - it would be simple to have a make win-dist that includes the Windows-build files (only) and the the normal make dist not containing them. If it helps to drop the split then I'd do a PR for this (this is obviously a bigger task [just needed to be done once] so I'd only do this if I can know that @wbhart and @BrianGladman would then work together in a single repository).

For the issue at hand I'd suggest to closing this (INSTALL is for tarballs and those are available as "nightlies" now).