cppqed-support

[Cppqed-support] git commits in version information

[Raimar S. <rai...@ui...>]

Dear András,

I have tackled the next point on the issues list: version information with git commit sha1 values. This is non-trivial if you want to have the git commits of _all_ repositories which make up a particular script. This can of course only be achieved in the scripts project itself, as only there all the other repositories are known (core, elements, custom elements, custom scripts).

Please have a look at C++QED_core (branch version) and CustomScriptsExample (branch version). These are branched from master, so you will need C++QED_elements and CustomElementsExample from master.

When you run 2ParticlesRingCavitySine --version, you will see something like:

# C++QEDcore Version 2.9.1, core git commit: b70df0f1ce07ba6c4cf4130fc6c7c5b29e82a95b
# elements git commit: f42c89e651211f572c75f363a368f2e67f0b6883
# elements_custom_example git commit: c2b9647117e47fd1f4d9e6714fe6079121756e1c
# scripts_custom_example git commit: 5417c29938df3dce9fcdb9b53f4a6ec0a859ee1b

# Andras Vukics, vu...@us...

# Compiled with
# Boost library collection : Version 1.54
# Gnu Scientific Library   : Version 1.15
# Blitz++ numerical library: Config date: Fri Aug 30 13:01:08 CEST 2013

When you run the simulation, you will notice that the exact same version information is included in the header of the data. This is made possible by adding the following line to the script:

updateVersionstring(cppqed_component_versions());

Without this call (all the original scripts), the version string will only contain the core git commit. To take advantage of the full version information, only "Version.h", "component_versions.h" and the call to updateVersionstring has to be included in a script.

When you add a new commit in one of the repositories, cmake will automatically be run to regenerate the correct version information. Only very little code containing the version string needs to be recompiled, the rest is done by relinking.

If you agree, I will merge this into master and Development.

Best regards
Raimar


Implementation details:

All libraries now have the function cppqed_*_version() returning the git commit as string, where * is core, elements, elements_custom_example etc. If the project name is "core" then also the numerical version of C++QED as defined in the CMakeLists.txt is included. The definition and declaration is auto-generated by cmake.

Additionally, script executables are linked with the autogenerated function cppqed_component_versions(), where all the cppqed_*_version() strings of the sub-components are combined. 

In the core library there is now a global variable cppqed_versionstring which is initialized with the core version information. The function updateVersionstring can be used in scripts to update the global variable with the more accurate version information given by cppqed_component_versions().  The global variable is then consulted via versionHelper() if --version is present on the command line and for the data header.

You can have a look at all the auto-generated .cc and .h files, they are in the top level build directories of the projects.

Re: [Cppqed-support] git commits in version information

[Raimar S. <rai...@ui...>]

I forgot to mention, this fails graciously if the git information is not 
found. In this case it will show "GITDIR-NOTFOUND" in the version instead of 
the commit.

Raimar

On Thursday, November 07, 2013 02:23:10 PM Raimar Sandner wrote:
> Dear András,
> 
> I have tackled the next point on the issues list: version information with
> git commit sha1 values. This is non-trivial if you want to have the git
> commits of _all_ repositories which make up a particular script. This can
> of course only be achieved in the scripts project itself, as only there all
> the other repositories are known (core, elements, custom elements, custom
> scripts).
> 
> Please have a look at C++QED_core (branch version) and CustomScriptsExample
> (branch version). These are branched from master, so you will need
> C++QED_elements and CustomElementsExample from master.
> 
> When you run 2ParticlesRingCavitySine --version, you will see something
> like:
> 
> # C++QEDcore Version 2.9.1, core git commit:
> b70df0f1ce07ba6c4cf4130fc6c7c5b29e82a95b # elements git commit:
> f42c89e651211f572c75f363a368f2e67f0b6883
> # elements_custom_example git commit:
> c2b9647117e47fd1f4d9e6714fe6079121756e1c # scripts_custom_example git
> commit: 5417c29938df3dce9fcdb9b53f4a6ec0a859ee1b
> 
> # Andras Vukics, vu...@us...
> 
> # Compiled with
> # Boost library collection : Version 1.54
> # Gnu Scientific Library   : Version 1.15
> # Blitz++ numerical library: Config date: Fri Aug 30 13:01:08 CEST 2013
> 
> When you run the simulation, you will notice that the exact same version
> information is included in the header of the data. This is made possible by
> adding the following line to the script:
> 
> updateVersionstring(cppqed_component_versions());
> 
> Without this call (all the original scripts), the version string will only
> contain the core git commit. To take advantage of the full version
> information, only "Version.h", "component_versions.h" and the call to
> updateVersionstring has to be included in a script.
> 
> When you add a new commit in one of the repositories, cmake will
> automatically be run to regenerate the correct version information. Only
> very little code containing the version string needs to be recompiled, the
> rest is done by relinking.
> 
> If you agree, I will merge this into master and Development.
> 
> Best regards
> Raimar
> 
> 
> Implementation details:
> 
> All libraries now have the function cppqed_*_version() returning the git
> commit as string, where * is core, elements, elements_custom_example etc.
> If the project name is "core" then also the numerical version of C++QED as
> defined in the CMakeLists.txt is included. The definition and declaration
> is auto-generated by cmake.
> 
> Additionally, script executables are linked with the autogenerated function
> cppqed_component_versions(), where all the cppqed_*_version() strings of
> the sub-components are combined.
> 
> In the core library there is now a global variable cppqed_versionstring
> which is initialized with the core version information. The function
> updateVersionstring can be used in scripts to update the global variable
> with the more accurate version information given by
> cppqed_component_versions().  The global variable is then consulted via
> versionHelper() if --version is present on the command line and for the
> data header.
> 
> You can have a look at all the auto-generated .cc and .h files, they are in
> the top level build directories of the projects.
> 

Re: [Cppqed-support] git commits in version information

[Andras V. <and...@ui...>]

Hi Raimar,
I suggest that we put the inclusion of "Version.h" and
"component_versions.h" into a header which is included by all scripts. A
straightforward choice is Evolution.h, which we then move from core to
scripts.
Also, this call:
updateVersionstring(cppqed_component_versions());
should perhaps be wrapped in the constructor of some class, of which we
then initialize a dummy instant in the scope of the global namespace. Scott
Meyers writes about how to do this correctly in issue 4 of Effective C++
(3rd edition), I will have to check.
Then, script writers will not be additionaly burdened by the
version-display issue.
What do you think?
Best regards,
András


On Thu, Nov 7, 2013 at 2:23 PM, Raimar Sandner <rai...@ui...>wrote:

> Dear András,
>
> I have tackled the next point on the issues list: version information with
> git commit sha1 values. This is non-trivial if you want to have the git
> commits of _all_ repositories which make up a particular script. This can
> of course only be achieved in the scripts project itself, as only there all
> the other repositories are known (core, elements, custom elements, custom
> scripts).
>
> Please have a look at C++QED_core (branch version) and
> CustomScriptsExample (branch version). These are branched from master, so
> you will need C++QED_elements and CustomElementsExample from master.
>
> When you run 2ParticlesRingCavitySine --version, you will see something
> like:
>
> # C++QEDcore Version 2.9.1, core git commit:
> b70df0f1ce07ba6c4cf4130fc6c7c5b29e82a95b
> # elements git commit: f42c89e651211f572c75f363a368f2e67f0b6883
> # elements_custom_example git commit:
> c2b9647117e47fd1f4d9e6714fe6079121756e1c
> # scripts_custom_example git commit:
> 5417c29938df3dce9fcdb9b53f4a6ec0a859ee1b
>
> # Andras Vukics, vu...@us...
>
> # Compiled with
> # Boost library collection : Version 1.54
> # Gnu Scientific Library   : Version 1.15
> # Blitz++ numerical library: Config date: Fri Aug 30 13:01:08 CEST 2013
>
> When you run the simulation, you will notice that the exact same version
> information is included in the header of the data. This is made possible by
> adding the following line to the script:
>
> updateVersionstring(cppqed_component_versions());
>
> Without this call (all the original scripts), the version string will only
> contain the core git commit. To take advantage of the full version
> information, only "Version.h", "component_versions.h" and the call to
> updateVersionstring has to be included in a script.
>
> When you add a new commit in one of the repositories, cmake will
> automatically be run to regenerate the correct version information. Only
> very little code containing the version string needs to be recompiled, the
> rest is done by relinking.
>
> If you agree, I will merge this into master and Development.
>
> Best regards
> Raimar
>
>
> Implementation details:
>
> All libraries now have the function cppqed_*_version() returning the git
> commit as string, where * is core, elements, elements_custom_example etc.
> If the project name is "core" then also the numerical version of C++QED as
> defined in the CMakeLists.txt is included. The definition and declaration
> is auto-generated by cmake.
>
> Additionally, script executables are linked with the autogenerated
> function cppqed_component_versions(), where all the cppqed_*_version()
> strings of the sub-components are combined.
>
> In the core library there is now a global variable cppqed_versionstring
> which is initialized with the core version information. The function
> updateVersionstring can be used in scripts to update the global variable
> with the more accurate version information given by
> cppqed_component_versions().  The global variable is then consulted via
> versionHelper() if --version is present on the command line and for the
> data header.
>
> You can have a look at all the auto-generated .cc and .h files, they are
> in the top level build directories of the projects.
>
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models.
> Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and
> register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> Cppqed-support mailing list
> Cpp...@li...
> https://lists.sourceforge.net/lists/listinfo/cppqed-support
>

Re: [Cppqed-support] git commits in version information

[Raimar S. <rai...@ui...>]

Hi András,

in principle this is a good Idea, I have also thought about how to get this to 
work without additional user action.

On Wednesday, January 08, 2014 15:17:55 Andras Vukics wrote:
> I suggest that we put the inclusion of "Version.h" and
> "component_versions.h" into a header which is included by all scripts. A
> straightforward choice is Evolution.h, which we then move from core to
> scripts.

Version.h is unproblematic, but component_versions.h is automatically 
generated and only available in the build directory of script projects. Only 
there all the components can be known. This can also include custom elements 
projects, about which C++QED knows nothing.

Therefore the header including component_versions.h must only be used by 
scripts.

> Also, this call:
> updateVersionstring(cppqed_component_versions());
> should perhaps be wrapped in the constructor of some class, of which we
> then initialize a dummy instant in the scope of the global namespace. Scott
> Meyers writes about how to do this correctly in issue 4 of Effective C++
> (3rd edition), I will have to check.

For the reason stated above, this call cannot be in any of the C++QED 
libraries. Maybe we can work with a template that gets instantiated by the 
script? But I'm not sure how to do this automatically, and I don't have the 
book at hand.

> Then, script writers will not be additionaly burdened by the
> version-display issue.
> What do you think?

That would indeed be very nice!

Best regards
Raimar