There is certainly a lot more to be done, but this is a first working version in so far as that the tarballs produced by make dist seem to work in tests. But since I have not year heard back about the documentation, I've also not made any efforts to include that...

Basically, someone (@fredrik-johansson ?) needs to tell me what else, if anything, should be added to the archive.

Also, which formats do you want (.tar.gz for sure; but something else? e.g. .zip, .tar.xz, .tar.zst, ... ?)

Lastly, this does not yet try to upload the generated tarballs anywhere, such as to a GitHub release. I can add something for that, but I need some more information on what is wanted. Perhaps we can briefly discuss it tomorrow.

I just realized I misunderstood @fredrik-johansson yesterday: I thought he was saying that FLINT already has the version in just one place. But that's wrong, it has it in multiple places. At least these:

• configure.ac: variable FLINT_VERSION is 3.0.0-dev right now
• configure.ac: variables FLINT_MAJOR + FLINT_MINOR + FLINT_PATCH
• src/flint.h: has

  #define __FLINT_VERSION 3
  #define __FLINT_VERSION_MINOR 0
  #define __FLINT_VERSION_PATCHLEVEL 0
  #define FLINT_VERSION "3.0.0-dev"
  

That's all I am aware of right now. If you know more, please let me know.

I will unify this to a single one.

Done now. Example of a GitHub release created using this: https://github.com/fingolfin/flint/releases/tag/v6.2.3-dev. You can see the corresponding workflow at https://github.com/fingolfin/flint/actions/runs/6488873277.

I'm not sure if it works, but I think it looks really good. I'd really like to see flint.h being configurable!

Do you mean you want it to generated from flint.h.in (which this PR does)?

Yes!

It offers some possibilities, but it also has a serious drawback in the current build system: one has to remember to edit flint.h.in, and then run ./config.status src/flint.h, otherwise it will keep using the old src/flint.h ... I have another PR in run to make it automate that, though, but I run into some bugs (?) with the build system... will open a PR and/or issue next.

Sounds good!

If you tell me the formula... ?

Well, I think we could just do

FLINT_MAJOR_SO = FLINT_MAJOR + 15
FLINT_MINOR_SO = FLINT_MINOR
FLINT_PATCH_SO = FLINT_PATCH

but I have no idea how the minor version numbers are supposed to work for SO versioning.

FLINT_MAJOR_SO = FLINT_MAJOR + 15
FLINT_MINOR_SO = FLINT_MINOR
FLINT_PATCH_SO = FLINT_PATCH

But as I argued, that would be wrong in general... The rules for soname versioning are explained in configure.ac, right above the definition of FLINT_MINOR_SO etc.. I am happy to talk about this today.

But perhaps it would make sense to first merge this, and then apply further improvements in a new PR?

It fails with cygwin/MSVC/cmake. I tried to modify CMakeLists.txt but clearly what I did was not right or not enough.

One intermediate solution would be to revert flint.h to not be generated, and instead add a flint-version.h which is generated, and included by flint.h (and then of course also needs to be installed).

Will look into it later, now need to take some more exams...

I believe doc/source/conf.py needs to be updated to read VERSION.

Will update doc/source/conf.py. But that file is weird:

# The short X.Y version
version = u''


for _line in open("../../configure.ac").readlines():
    if _line.startswith("define(FLINT_VERSION,"):
        _i1 = _line.find('[')
        _i2 = _line.find(']', _i1 + 1)
        version = _line[_i1+1:_i2]

# The full version, including alpha/beta/rc tags
release = version

So the comments say release and version are different, but in practice they are defined to the same value... Is that intentional or just a bug?

So the comments say release and version are different, but in practice they are defined to the same value... Is that intentional or just a bug?

I think it currently doesn't matter since the documentation isn't versioned.

The problem on Cygwin seems to be caused by VERSION having a trailing newline, which then is converted to "CRLF" on Windows... For now I "solved" this by removing this newline. The dev/make_dist.sh script also now uses printf instead of echo to ensure it keeps that way.

If desired I could also make a modification which makes configure.ac more robust against that, but perhaps it can wait for a follow-up PR so that @fredrik-johansson does not have to wait even longer.

All green; I will take it :-)

FLINT v3, let's go!

🏎️

FLINT_MAJOR_SO = FLINT_MAJOR + 15
FLINT_MINOR_SO = FLINT_MINOR
FLINT_PATCH_SO = FLINT_PATCH

But as I argued, that would be wrong in general... The rules for soname versioning are explained in configure.ac, right above the definition of FLINT_MINOR_SO etc.. I am happy to talk about this today.

But perhaps it would make sense to first merge this, and then apply further improvements in a new PR?

What is the the historical reason for the + 15?

I have tried to make a v3.0.0-rc1 on the flint-3.0 branch, but on that branch Cygwin CI is still failing with:

checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/cygdrive/d/a/flint/flint':
configure: error: C compiler cannot create executables
See `config.log' for more details
Error: Process completed with exit code 77.

Obviously, I failed to remove the newline. Well, this isn't very convenient.

You should not have modified the VERSION file in the first place, though, just create the tag and it'll do that for you

OK. I tried to tag again and this time Cygwin passes configure. However, the release workflow isn't being run for some reason.

Edit: now it is.

I think I'm having an aneurysm doing this on train wifi.

There is now a 3.0.0-rc1 release which may or may not be correct. You're welcome to test it.

hmm? https://github.com/flintlib/flint/actions Shows it did run?

Yes indeed.