[SOLVED] Getting Lazarus version in Ifdef

[aydın]

Symbols of used units are only added once the whole uses section has been parsed.

I thought so.

I don't think there is a solution then, because I need it in the interface section.
In fact, adding multiple uses to the interface section would have solved the problem.

Maybe it will come in future FPC versions.

[JuhaManninen]

I don't think there is a solution then, because I need it in the interface section.

I still wonder why you need it? Is it about the LazUTF8Classes and LazUTF8SysUtils units? They were needed with an ancient FPC version which you certainly don't use. Just leave them out.
See my other post in this same thread.

[MarkMLl]

I don't think there is a solution then, because I need it in the interface section.
In fact, adding multiple uses to the interface section would have solved the problem.

That's why, in the link I gave you, my code went to quite a lot of trouble to work out what facilities were available before getting to the uses clause.

Not checked with v3, not sure I can be bothered.

MarkMLl

[aydın]

I still wonder why you need it?

You're right, it looks like I don't need it right now.
But someone or I may need it.

I think this is a key feature, this issue should be resolved.

But I think I got what I wanted.

[wp]

I don't think there is a solution then, because I need it in the interface section.

I still wonder why you need it? Is it about the LazUTF8Classes and LazUTF8SysUtils units? They were needed with an ancient FPC version which you certainly don't use. Just leave them out.
See my other post in this same thread.

LazUTF8Classes and LazUTF8SysUtils are contained in Laz 2.2.6 - I would not call this "ancient"...

A use case of this feature could be a package supposed to work across a wide range of FPC/Laz versions. Here a version-dependent uses clause might be helpful (although it can be by-passed by a package-wide define in an include file checked by {$IFDEF ...} ).

[JuhaManninen]

LazUTF8Classes and LazUTF8SysUtils are contained in Laz 2.2.6 - I would not call this "ancient"...

A use case of this feature could be a package supposed to work across a wide range of FPC/Laz versions. Here a version-dependent uses clause might be helpful (although it can be by-passed by a package-wide define in an include file checked by {$IFDEF ...} ).

They are contained in Laz 2.2.6 but not needed any more there. That's why they were deprecated for years.
LazUTF8Classes became obsolete with FPC 3.0 + codepage aware string types. It became obsolete already before being deprecated.
LazUTF8SysUtils was renamed because it had nothing to do with UTF8. Again it was deprecated for years, so it should not cause problems to any maintained code.

I think this is a key feature, this issue should be resolved.

Not really. In rare cases when a unit is removed from a public package, it is deprecated for a long transition period. It seems neither you nor the maintainers of BGRA read the deprecated warnings.
Please read what I wrote above.
LazUTF8Classes is not needed after FPC 2.x. Are you seriously still using such an old compiler?
Renaming LazUTF8SysUtils is not tied to FPC version but it was deprecated for many many years. Do you mean your code must compile with LazUtils from many many years ago? Why?

[aydın]

LazUTF8Classes is not needed after FPC 2.x. Are you seriously still using such an old compiler?
Renaming LazUTF8SysUtils is not tied to FPC version but it was deprecated for many many years. Do you mean your code must compile with LazUtils from many many years ago? Why?

No, but I thought it might be needed, maybe not for this but for something else.

As I said, I think I got what I wanted.

[KodeZwerg]

Since you wasnt clear enough with your "it must be in interface part" statement, if it is about class design and missing classes/methods/types etc, just create in interface an empty class and structure it in implementation, just an idea.