Generate version header

[ZedThree]

This solves a problem with the CMake system: everything gets rebuilt on every commit because -DBOUT_VERSION* are passed on the command line to every file, and CMake knows that if the preprocessor macros for a file change then the file needs to be rebuilt.

This is solved by adding include/bout/version.hxx which is generated by the build system from include/bout/version.hxx.in. This header contains constexpr variables in the bout::version:: namespace, and replaces the preprocessor macros BOUT_VERSION, REVISION, BOUT_VERSION_STRING and BOUT_VERSION_DOUBLE.

It might be nice to mark those macros as deprecated somehow. Not found a nice portable way so far!

There's a little funkiness with the makefile build system: BOUT_REVISION (renamed from REVISION) is still passed to each file via the command line. I couldn't see a way round this, which is why version.hxx.in still has an #ifndef in it.

Also, there is a potential issue here: if in one cxx file you take the address of a constexpr variable defined in a header, you may/will get a different address than in another cxx file. C++17 solves this with inline variables.
Mostly we shouldn't be taking the address of constexpr variables, but unfortunately, this is how Datafile::add works. Basically, don't call Datafile::add on the same bout::version variable twice in different files, or it will throw. But you probably shouldn't be doing that anyway!

Lastly, there's a bunch of unrelated changes to configure because I think the gettext macro has been updated on my system. Happy to pull those changes out into a separate PR.

[johnomotani]

I guess this is a breaking change. People probably not using BOUT_VERSION, etc. but if they are the names have changed. Needs adding to a 4to5 script?

[ZedThree]

Yes, probably wise!

[ZedThree]

Possible gotcha: if you build with ./configure and then with CMake, it will pick up the makefile system version of include/bout/revision.hxx, not the CMake generated one.
make distclean now cleans up the generated headers.

I'm now happy that this does what we want for CMake: on commit revision.hxx is regenerated, only bout++.cxx gets recompiled, and all the executables only get relinked and not rebuilt.

bin/bout-v5-macro-upgrader.py does a "best effort" attempt to convert macros to variables, add the necessary headers, and remove unneeded #ifdefs. It doesn't attempt to expand other macros or fix #ifndefs as this got tricky very quickly: a simple replacement might not be correct.

[johnomotani]

Nice! This works for me. Will save lots of time compiling when I have to commit everything to debug Travis runs...

Would be nice to add a section to the manual listing the breaking changes, and the scripts available to apply the necessary updates.

[johnomotani]

It doesn't attempt to expand other macros or fix #ifndefs as this got tricky very quickly: a simple replacement might not be correct.

Would it be worth adding some warnings to flag up any uses that weren't fixed? The compiler should give errors there anyway, but I think it would be friendlier if this script gave a warning.

[ZedThree]

Good point. We're now not defining those macros, so #ifndef sections will suddenly get compiled.
Maybe remove the #ifndef lines and also flag a warning?

[ZedThree]

This now takes care of situations like the contrived:

-#ifndef BOUT_VERSION_STRING
-#ifdef REVISION
-  output_progress.write(_("BOUT++ version {:s}\n"), BUILDFLAG(REVISION));
-#else
-  output_progress.write(_("BOUT++ version {:s}\n"), "Unknown");
-#endif
-#else
-  output_progress.write(_("BOUT++ version {:s}\n"), BOUT_VERSION_STRING);
-#endif
-#ifdef REVISION
-  output_progress.write(_("Revision {:s}\n"), BUILDFLAG(REVISION));
-#endif
-#ifndef REVISION
-  output_progress.write(_("Revision {:s}\n"), "Unknown");
-#endif
+  output_progress.write(_("BOUT++ version {:s}\n"), bout::version::full);
+  output_progress.write(_("Revision {:s}\n"), BUILDFLAG(bout::version::revision));

I consider all these upgrader scripts as "best effort only" and somewhat dangerous. The output must be checked by the users, so there's no specific warning for this one. When I get them all into a single framework type thing, it'll have a big flashing warning.