Hi all.

When building a program or a library with Lazarus I can embed in the resulting program (or library) version information (project properties, version tab).
In a Windows environment I can retrieve this information using the properties option on the explorer right click.

Do you know someting similar I can use in Linux to display the version information either for a normal program or a library (.so) ?

Thanks,

Antonio.

Version Info Unit:
http://www.lazarus.freepascal.org/index.php/topic,12435.msg63887.html#msg63887

2012/9/17 Antonio Fortuny

Le 17/09/2012 15:18, Alexsander Rosa a ?crit :

Version Info Unit: http://www.lazarus.freepascal.org/index.php/topic,12435.msg63887.html#msg63887

I've already my own routines to get the program (or library) version numbers from Windows.
The sources commented on that forum look like Windows too. My concern is about Linux.

It works on Linux.

2012/9/17 Antonio Fortuny

Le 17/09/2012 16:12, Alexsander Rosa a ?crit :

It works on Linux.

Indeed. My problem is to obtain the same information for any other file and not only for my own one. Again for this I already have some other functions.

what if, the version prgram is vpgm and I do:
vpgm /folder/progs/anotherprogram
for which I do not have a handle and is even not loaded.

As the function to get the resources works with the handle, this will not work anyway. same for a library which cannot be launched on its own.

Antonio.

Do you have control over this other program? When I need this for my own software, I usually add a "--version" command line option. When called with "--version" the program outputs the version and terminate.

2012/9/17 Antonio Fortuny

Alexsander Rosa wrote

software, I usually add a "--version" command line option. When called with "--version" the program outputs the version and terminate.

Same here. Under Linux, that is all you can do (as far as I know). No desktop environment (like KDE, Gnome, XFCE etc) has a "Version Information" tab in the file properties.

As for libraries, Linux (and most *nix systems) have a well established naming convention where the version number is part of the filename. I find this actually better than Windows - thus you can have multiple versions installed at the same time.

eg:
libfbclient-2.0.so
libfbclient-2.5.2.so

Regards,
- Graeme -

I sympathise with the OP though: the Lazarus IDE has facilities to insert version information, so how can you get at that even if it means running the program (without necessarily displaying a form etc.) to extract it?

And for that matter, how can one merge svn information into it? :-)

Mark Morgan Lloyd wrote

I sympathise with the OP though: the Lazarus IDE has facilities to insert version information, so how can you get at that even if it means

Yeah, those options are pretty pointless on any platform - except Windows.

And for that matter, how can one merge svn information into it? :-)

All my apps, linux & windows, gui & console, supports a --version parameter. When I want to include repository information like SHA1 (git) or Revision (svn), then I use include files that set a value for a version constant. I do the same for the FPC version.

For example, here are some constants for one of my apps...

NOTE the formatting for FPC version and application compiled date. They are like macros.

   cMajorVersion             = 3;
   cMinorVersion             = 0;
   cBuildVersion: string     = {$I revision.inc} // '006-rc1';
   cCompileDateTime: string  = {$I %date%} + ' ' + {$I %time%};
   cFPCVersion: string  = {$I %fpcversion%};
   // Name + cMajorVersion + cMinorVersion + Build + cBuildVersion
   cAppNameFormatStr         = '%s v%d.%2.2d (%s %s)';
   // Name + cMajorVersion + cMinorVersion + Centre
   cAppNameCentreFormatStr   = '%s v%d.%2.2d - [%s]';
   cAppNameCGI               = '%s v%d.%2.2d';

I also have a VERSION-GEN script that gets executed before I do a Build All. It generates output as shown below, which I normally pipe into a *.inc file, and get set as a constant in my application.

      '3.0.12.9.gbcfb.dirty';

This gives me lots of information:
3 - major version
0 - minor version
12 - build number
9 - commits since the last released version (v3.0.12) gbcfb - the SHA1 value of the last commit in my git repository (if you don't know git, this is live a revision number) dirty - this tells me the build was made, but I had local changes that wasn't committed in the repository yet.

The next released version will be v3.0.13 - we don't really use the minor version number in our company software. The formatting string above shows how we display version information to the end-user.

Regards,
- Graeme -

? The fileinfo unit distributed with FPC can do it for any file that has resources compiled in. It's currently only deployed on windows, but I have a modified version that works on any platform.

All it needs is the filename. Note that on non-windows, the file you open must have FPC-style (i.e. windows style) version info compiled-in.

Michael.

Le 17/09/2012 16:57, Alexsander Rosa a ?crit :

Do you have control over this other program? When I need this for my own software, I usually add a "--version" command line option. When called with "--version" the program outputs the version and terminate.

Ok, sounds good. But, again, what I need is the version of another program or library which cannot be executed, just read.

Let's put it in another way.
As Lazarus seems to glue the version information with the compiled result (as resource data), how can I retrieve this information from any other file ?

FPC and Lazarus WiKi do only talk about the compiled target, not how to extract resource data from other files. Of course, they have to be compiled with FPC.

Antonio.

The fileinfo unit in FPC has this ability.

Michael.

yep but only for Windows (and WinCE), not Linux as they call GetFileVersionInfoSizeA and GetFileVersionInfoSizeW in version.dll to read the resource data information

Antonio.

Yes.
But as I wrote in another mail in this thread:
I have a modified version of that unit that works for Linux as well; I use it in production.

Here is the relevant part for non-windows:

uses resource, elfreader, versiontypes,versionresource;
Type
   TVersionQuad = Array[1..4] of Word;
Function GetFileVersion (Const AFileName : string; Var Version : TVersionQuad) : Boolean;
Var
   RS : TResources;
   E : TElfResourceReader;
   VR : TVersionResource;
   I : Integer;
begin
   RS:=TResources.Create;
   try
     E:=TElfResourceReader.Create;
     try
       Rs.LoadFromFile(AFileName,E);
     finally
       E.Free;
     end;
     VR:=Nil;
     I:=0;
     While (VR=Nil) and (I<RS.Count) do
       begin
       if RS.Items[i] is TVersionResource then
          VR:=TVersionResource(RS.Items[i]);
       Inc(I);
       end;
     Result:=(VRNil);
     if Result then
       For I:=1 to 4 do
         Version[i]:=VR.FixedInfo.FileVersion[I-1];
   Finally
     RS.FRee;
   end;
end;

Better yet would probably be to commit it in FPC SVN. I'll look into that as well :-)

Michael.

Le 18/09/2012 09:21, a ?crit :

Definitely great !
Thanks Michael

Your implementation of reading the file resources differs a little from Paul's
(http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100723/8db6b97e/attachment.ksh). Are there any merits for each one?

Stephano

Let's make absolutely certain we're "on the same page": Options for Project: x -> Version info.

Perhaps the whole thing should be greyed out for targets where there isn't a reliable reader? (Apologies is somebody already has organised a reader for e.g. Linux, I've missed some messages in the thread).

> And for that matter, how can one merge svn information into it? :-) All my apps, linux & windows, gui & console, supports a --version parameter.

I think that --help and --version should be universally supported where stdout is available, particularly on unix targets where GNU is relevant.

When I want to include repository information like SHA1 (git) or Revision (svn), then I use include files that set a value for a version constant. I do the same for the FPC version.

So do I. But is the version insertion stuff is relevant, how can that be transferred automatically?

Wishlist: a predicate to allow a file's existence to be tested, so that a project can only try to include it if it's actually there.

Mark Morgan Lloyd hat am 18. September 2012 um
11:35 geschrieben:

That was so at the beginning. But users complained because they want to edit the windows properties on other targets as well.

[...]

Mattias

Yes, that's the info I'm talking about. In Windows you can right click on a file, select Properties, and then see the Version Information tab with all that details. Even the embedded icon in the resources is used as the default icon in Windows Explorer, on the desktop etc.

Under Linux (KDE, Gnome, XFCE etc) there is no application that can pull such information out of a ELF binary. Under Linux, icons are separate PNG (or xpm) files. In Nautilus (Gnome) or Dolphin (KDE) or Thunar (XFCE) you can right click on those executables, but there will be NO version information being displayed anywhere.

Only FPC written and compiled programs couldn't exact that information for FPC written and compiled programs. No linux distro ships with FPC written and compiled programs.

So like I said, that information is pretty pointless to Linux systems.

The Version Info is only handy, when you want to set the version information [to be displayed under Windows], while you might be developing that app under a Linux environment.

Regards,
- Graeme -

His version starts with a handle, which requires loading the module. I am not sure (as in: I simply do not know) whether you can load an executable or DLL without running them and obtain the correct handle.

Mine simply starts from a filename.

Michael.

More to the point, the various desktops etc. each have their own description of a shortcut (or equivalent by some other name) that can appear in a menu or on the desktop.

Getting a program's version number or outline help information /should/ be in the scope of the xdg utilities, but appears not to be implemented. Until then, the best that can be done is to rely on every program implementing --version and --help.

You can pass a flag to LoadLibraryEx that tells Windows to load it only as a data file (works with DLL and EXE alike).

Regards,
Sven