Hi,

Is there a way to get Lazarus version from a package? I know about LazarusVersionStr constant from {$LazarusDir}/IDE/lazconfig.pp, but that's not accessible from a package. I can create a patch if necessary, but I was hopping somebody already did it.

Thanks you!

Balázs

Use unit lclversion.

Mattias

>@Mattias >Use unit lclversion.

Thank you! :)

Balázs

It would be good to have an option in the package system to write and/or register the package version somewhere, so it is accessible at runtime, and an application can query the various packages and their versions.

I have integrated such a registration in my build system, but a 'native' solution would be preferable.

Just a thought.

Michael.

[...] It would be good to have an option in the package system to write and/or register the package version somewhere, so it is accessible at runtime, and an application can query the various packages and their versions.

AFAIK most users asked for the version at compile time. So it must be either a define or some consts in an unit like lclversion does. The defines would create many ugly FPC parameters, fpmake can't create them.
The 'version unit' is compatible with all build systems and works at runtime too. It is not supported by codetools yet though. Maybe the IDE can automatically update/create such version units.

Mattias

I'm not sure we're talking about the same thing. I don't know what 'version unit' you mean ?

I have software which consists of many different packages which we control, from different SVN repos. In order to correctly identify the version of each package on a production system, I need somewhere a registry of versions of all used packages.

For each package I now create an include file with a version string which is written to a central registry. At runtime I query the registry and display for all used packages the version number.

As far as I know, the version number of a lazarus packages lives outside the sources, it resides just in the LPK. I now use some XML routines to extract this version number from the .lpk and write it in the abovementioned include file. This happens in our build system.

I don't necessarily expect lazarus to provide such a central registry, but to be able to have a version unit for each package would be nice, so I no longer need to do the XML trickery or adapt the build system manually...

But please, this is a nice to have, it was just a thought after seeing the lclversion tip.

Michael.

[...] I'm not sure we're talking about the same thing. I don't know what 'version unit' you mean ?

For example lazarus/lcl/lclversion.pas

[...] As far as I know, the version number of a lazarus packages lives outside the sources, it resides just in the LPK.

Yes.

I now use some XML routines to extract this version number from the .lpk and write it in the abovementioned include file. This happens in our build system.

The IDE could write the version to some file (or update an existing file). What would be a good place?
For example when package A needs to know the version of a required package B the version must be stored either in a unit of A or B. Storing it in B avoids redundancy, but when B is read only it needs to be stored in A.

Mattias

Mattias Gaertner wrote

On Tue, 8 Nov 2016 13:08:41 +0100 (CET)Michael Van Canneyt wrote: > [...]> I'm not sure we're talking about the same thing. I don't know what 'version> unit' you mean ? For example lazarus/lcl/lclversion.pas

I don't want to hijack anybody else's thread, but I habitually use that file to get version info so that I can always find out what compiler etc. has been used to build a binary. The one downside of this is that I end up with a -Fu $(LazarusDir)/lcl which (I suspect) contributes to the entire LCL being rebuilt more often than is strictly necessary.

How does lclversion tell you the used compiler?

The one downside of this is that I end up with a -Fu $(LazarusDir)/lcl which (I suspect) contributes to the entire LCL being rebuilt more often than is strictly necessary.

Alternative: add lclbase as requirement in the project inspector.

Mattias

Yeah I'm confused too... Instead simply something like the following:

===========================================
Program InfoDemo;
Const
  User = {$I %USER%};
begin
  Write ('This program was compiled at ',{$I %TIME%});
  Writeln (' on ',{$I %DATE%});
  Writeln ('By ',User);
  Writeln ('Compiler version : ',{$I %FPCVERSION%});
  Writeln ('Target CPU : ',{$I %FPCTARGET%});
end.
===========================================

Creates the following output:

This program was compiled at 16:36:18 on 2016/11/09 By graemeg
Compiler version : 2.6.4
Target CPU : x86_64-freebsd

Regards,
Graeme

Mattias Gaertner wrote

On Tue, 8 Nov 2016 15:20:22 +0000Mark Morgan Lloyd via Lazarus wrote: > On 08/11/16 13:30, Mattias Gaertner via Lazarus wrote:> > On Tue, 8 Nov 2016 13:08:41 +0100 (CET)Michael Van Canneyt wrote: > >> [...]> I'm not sure we're talking about the same thing. I don't know what 'version> unit' you mean ? > > For example lazarus/lcl/lclversion.pas > > I don't want to hijack anybody else's thread, but I habitually use that > file to get version info so that I can always find out what compiler > etc. has been used to build a binary. How does lclversion tell you the used compiler?

I said compiler /etc./

           lazV= 'Lazarus IDE v' + (*$I version.inc *) ;
           lclV= 'Lazarus Class Library v' + lcl_version;
           fpcV= 'Free Pascal v' + (*$I %FPCVERSION% *) ;
           fpcC= ' for ' + (*$I %FPCTARGETCPU% *) ;
           fpcO= (*$I %FPCTARGETOS% *) ;

..and much other stuff, almost all captured at build although in some cases post-processed.

> The one downside of this is that I > end up with a -Fu $(LazarusDir)/lcl which (I suspect) contributes to the > entire LCL being rebuilt more often than is strictly necessary. Alternative: add lclbase as requirement in the project inspector.

Thanks, I'll try that. Is there an easy way to get the version.inc file without specifying an absolute path? At the moment I'm using -Fi (or rather, the equivalent in the paths dialogue).

A unit in the package. If you need the version, you use the unit. packagename_version.p(p|pas)

For example when package A needs to know the version of a required package B the version must be stored either in a unit of A or B. Storing it in B avoids redundancy, but when B is read only it needs to be stored in A.

Well, I will always control every package, so for me this question is academic. But it seems to me that if B doesn't provide the version, then the user is simply out of luck. If you really want to go that far, you could split the option in the package options:

[x] Generate unit with version number
[x] Generate version numbers for all used packages

Then

unit a_version;
interface
   AVersionStr  = '1.2.3';
   BversionStr  = '2.3.4';
implementation
end.

Or somesuch...

Michael.

packagename_version.p(p|pas)

Ok. Although if we make it configurable, we can use it for lclversion.pas as well.

[...] [x] Generate unit with version number

Ok. Needs update when saving the package.

[x] Generate version numbers for all used packages

Ok. Needs update when compiling the package. So the IDE and lazbuild can do that. fpmake cannot.

To make compare operations simple I suggest to use the lclversion scheme:

const
  lcl_major = 1;
  lcl_minor = 7;
  lcl_release = 0;
  lcl_patch = 0;
  lcl_fullversion = ((lcl_major *  100 + lcl_minor) * 100 +
lcl_release) * 100 + lcl_patch;
 lcl_version = '1.7';

Mattias

Your proposals sound all very well.

Michael.