Run-time deprecation warning for native Windows, 32-bit systems, ParFORM and Checkpoint

[tueda]

This is an implementation of deprecation messages like those in #475 (comment) but at runtime startup rather than at build time, for Windows, 32bit builds and ParFORM.

End users may not build binaries themselves. 32-bit binaries and ParFORM are distributed by various distributors. We can distribute native Windows binaries if #511 is merged and Delete Windows binaries in deploy.yml is removed. This patch will cause these end users to see annoying deprecation warnings.

The deprecation warning looks like, for example, for ParFORM:

DeprecationWarning: We are considering deprecating the MPI version (ParFORM).
If you would like support to continue, please leave a comment at:

    https://github.com/vermaseren/form/issues/xxxxx

Otherwise, it will be discontinued in the future.
To suppress this warning, use the --ignore-deprecation command line option or
set the environment variable FORM_IGNORE_DEPRECATION=1.

This warning can be suppressed by the (undocumented) --ignore-deprecation option or the environment variable FORM_IGNORE_DEPRECATION=1.

TODO: we need 3 separate issues for users to leave comments regarding the deprecation.

[coveralls]

coverage: 50.721% (-0.02%) from 50.74%
when pulling 58403cc on tueda:runtime-deprecation-warning
into 1d5e40b on vermaseren:master.

[jodavies]

A run-time message seems good, as you say users may just use the distributed binaries rather than compiling themselves. This would be the first "--" option, is it more consistent to use a single "-" like -pipe? I have no strong opinion there.

[tueda]

I was considering the convention for long-name options in GNU tools (other than GCC), but this makes sense (-pipe already exists). I'll switch it to -ignore-deprecation.

If you have a better name than -ignore-deprecation/FORM_IGNORE_DEPRECATION, then let me know.

[tueda]

Added a deprecation warning for the checkpoint as well, as discussed during the video call.

Though it says we are considering the deprecation of the checkpoint mechanism, I maintained the checkpoint code for the deprecation warning flag.

[tueda]

Now the issue numbers are linked to actual issues.

[jodavies]

This looks fine, let's see if anyone ever comments...

[tueda]

OK, it's been merged.

[tueda]

I haven't cherry-picked it into 4.3.

I don't remember why (maybe I simply missed them), but should all of the last arguments of PADPOSITION be incremented? So, it should be:

#ifdef WITHFLOAT
#ifdef WITHPTHREADS
	PADPOSITION(17,30,62,84,(sizeof(pthread_rwlock_t)+sizeof(pthread_mutex_t)*2)+2);
#else
	PADPOSITION(17,28,62,84,2);
#endif
#else
#ifdef WITHPTHREADS
	PADPOSITION(17,30,62,84,(sizeof(pthread_rwlock_t)+sizeof(pthread_mutex_t)*2)+2);
#else
	PADPOSITION(17,28,62,84,2);
#endif
#endif

The commit 7b48c35 incremented only the last argument of the second PADPOSITION.

[jodavies]

Right, yes. In practice I don't think the explicit padding is required these days but we shouldn't let the numbers get "out of date" in the macros.

[tueda]

OK, I'll push the fix. Thanks.

[tueda]

It seems that when I was editing the code, I overlooked the code blocks that were greyed out by VS Code (for vorm)... I need to be more careful...