[SOLVED] Getting Lazarus version in Ifdef

[aydın]

Hello everyone,

I know there is a unit called LazVersion that can be used to get this information, but I need it at compile time.

I am having a problem with my package when I try to make it compatible with Lazarus 3.0. Some of the names of the Laz units have changed and it is causing problems.

This is what i want:

Code: Pascal  [Select][+][-]

1. {$if LazVersion >= 3}
2.   // Codes
3. {$endif}
4.  

Thanks you in advance for your helps.

[MarkMLl]

I'm not sure whether it can be done without introducing a dependency on the Lazarus source files.

See e.g. https://github.com/MarkMLl/Mastech_ms2115b/blob/main/inifiles/trunk/inifilesabout.pas and look for HAS_LCLVERSION

MarkMLl

[wp]

Unit LazVersion contains this:

Code: Pascal  [Select][+][-]

1. const
2.   ...
3.   laz_fullversion = ((laz_major *  100 + laz_minor) * 100 + laz_release) * 100 + laz_patch;

Therefore, you add LazVersion to "uses" and then you can against check Laz_FullVersion. For example, if you want to distingish whether the Lazarus version is 2.2.6 or newer then you can insert this:

Code: Pascal  [Select][+][-]

1. uses  ..., LazVersion, ...;
2.  
3. {$IF Laz_FullVersion >= 2020600}  
4.   // do this
5. {$ELSE}
6.   // do that
7. {$ENDIF}

Note that the Laz_FullVersion is relatively new (can't remember the version in which it was introduced), in older versions you use unit LCLVersion and check against LCL_FullVersion.
 

[aydın]

Wow, I didn't know that consts could be used with $If.

But it seems like the Lazarus highlighter doesn't support it.

Thanks wp and MarkMLl.

[aydın]

This code is in BGRAUTF8.

Code: Pascal  [Select][+][-]

1. BGRAClasses, SysUtils, math, BGRAUnicode, LazVersion
2.   {$IFDEF BGRABITMAP_USE_LCL},
3.     {$IF laz_major >= 3}
4.       Classes
5.     {$ELSE}
6.       lazutf8classes
7.     {$ENDIF}
8.   {$ENDIF};
9.  

"{$IF laz_major >= 3}" will throw an error.

Code: [Select]

bgrautf8.pas(12,9) Error: Incompatible types: got "AnsiString" expected "Int64"
I couldn't figure it out.

[Josh]

does this work

Code: Pascal  [Select][+][-]

1. ,LazVersion, {$if laz_version >='3.0.0'} units for 3{$else}units for 2{$endif},

[JuhaManninen]

"{$IF laz_major >= 3}" will throw an error.

Code: [Select]

bgrautf8.pas(12,9) Error: Incompatible types: got "AnsiString" expected "Int64"I couldn't figure it out.

This is from unit LazVersion (package LazUtils) :

Code: Pascal  [Select][+][-]

1. const
2.   laz_major = 3;
3.   laz_minor = 99;
4.   laz_release = 0;
5.   laz_patch = 0;
6.   laz_fullversion = ((laz_major *  100 + laz_minor) * 100 + laz_release) * 100 + laz_patch;
7.   laz_version = '3.99.0.0';
8.  

"laz_major" should work in integer context. I believe it worked when it was added to BGRAUTF8.
I don't know why you get an error there.

[JuhaManninen]

I am having a problem with my package when I try to make it compatible with Lazarus 3.0. Some of the names of the Laz units have changed and it is causing problems.

I am curious, which unit names changed?
User programs use LazUtils, LCL and other packages included in Lazarus distribution.
Two deprecated units were removed from LazUtils. This apparently triggered the change in BGRA code. I believe the IFDEF there is completely useless. LazUTF8Classes has not been needed since FPC 3.0 when the codepage aware String was introduced. That was a long time ago.
I doubt BGRA compiles with ancient FPC 2.x. They could just dump that IFDEF and do as told here :
 https://wiki.freepascal.org/Lazarus_3.0_release_notes#LazUTF8Classes_and_LazUTF8SysUtils_units

[aydın]

does this work

Code: Pascal  [Select][+][-]

1. ,LazVersion, {$if laz_version >='3.0.0'} units for 3{$else}units for 2{$endif},

No, this dont't working.

With {$if laz_version >= '3.0.0'}, this {$if laz_version >= '4.0.0'} produces the same result.

It seems like the problem is in FPC.

[KodeZwerg]

Works as expected.

Code: Pascal  [Select][+][-]

1. uses LCLVersion
2.  
3.  
4.   {$IF Declared(lcl_major) and (lcl_major = 2)}
5.     ShowMessage('Version 2');
6.   {$ELSEIF Declared(lcl_major) and (lcl_major = 3)}
7.     ShowMessage('Version 3');
8.   {$ENDIF}
9.  

[aydın]

They work fine in normal code lines, but they behave strangely in the Uses section.

[KodeZwerg]

Still works as expected.

Code: Pascal  [Select][+][-]

1. interface
2.  
3. uses
4.   LCLVersion
5.  
6. ...
7.  
8. implementation
9.  
10. uses
11.   {$IF Declared(lcl_major) and (lcl_major = 2)}
12.     unitV2
13.   {$ELSEIF Declared(lcl_major) and (lcl_major = 3)}
14.     unitV3
15.   {$ENDIF}
16.   ;

[wp]

Juha, I see that you are reading this thread:

• Normally the inactive part of an {$IFDEF...} directive is grayed out which is an excellent feature. However, it does not work with {$IF...} which always grays out the wrong part. See attached screenshot: Although I am on Laz/main (v3.99 --> Laz_FullVersion = 3990000) the "{$IF Laz_FullVersion >= 3000000"} part is grayed.
• Using the version check in the interface uses clause results in a compile time error at the $IF: "unit1.pas(9,7) Error: Compile time expression: Wanted Boolean but got <erroneous type> at IF or ELSEIF". It can be bypassed by quoting the version number, i.e. making it a string. Strange...

[JuhaManninen]

Juha, I see that you are reading this thread:

• Normally the inactive part of an {$IFDEF...} directive is grayed out which is an excellent feature. However, it does not work with {$IF...} which always grays out the wrong part. See attached screenshot: Although I am on Laz/main (v3.99 --> Laz_FullVersion = 3990000) the "{$IF Laz_FullVersion >= 3000000"} part is grayed.
• Using the version check in the interface uses clause results in a compile time error at the $IF: "unit1.pas(9,7) Error: Compile time expression: Wanted Boolean but got <erroneous type> at IF or ELSEIF". It can be bypassed by quoting the version number, i.e. making it a string. Strange...

OK, yes. It is not only about coloring by editor. The compiler actually gives an error in uses section.

[PascalDragon]

They work fine in normal code lines, but they behave strangely in the Uses section.

Symbols of used units are only added once the whole uses section has been parsed. So it's simply not possible to use a define declared in another unit in the same uses-clause the unit is used in.