Jump to content
Tommi Prami

Call for Delphi 12 Support in OpenSource projects.

Recommended Posts

Yellow,

 

Now that there is "Public" Beta of Delphi 12. ( https://blogs.embarcadero.com/delphi-supports-android-api-33-via-yukon-beta/ )

Some OSS component/library supporters have already made "Educated guess" what there need to be done to support D12, making packages and so.


If possible/time/willing to make such a guess, please do, I think it would make everyone's job easier to test the Beta, since almost all of products made with Delphi, use some kind of Open source libs. I think it would just help all people in beta, even if maintainer would not be. In some cases making packages are trivial thing, but quite waste of time if everyone in Beta will do it themselves.

 

Like the great folks maintaining: 


(Just to mention two I've noticed)

 

-Tee-

Edited by Tommi Prami
Added llink

Share this post


Link to post

Even if the beta is "public", it's still under a NDA between Ambarcadero and the beta tester. Any threads or changed in public repositories about Yukon features violate the NDA.

  • Like 1

Share this post


Link to post
4 minutes ago, Patrick PREMARTIN said:

..or changed in public repositories about Yukon features violate the NDA.

That would depend on what the exact wording of the NDA is. For instance does having something like this in source code:

{$IF CompilerVersion > 35}

Violate the NDA?

Share this post


Link to post

I would say no. It's not hard to guess what the next compiler version will be. 

 

However, publishing packages saved with that beta may well be an NDA violation. 

Share this post


Link to post

In my opinion (as I understand the NDA), if you condition parts of the code with the next version's compiler, it's to use a possible feature of that version. In that case, it's a violation of the NDA, which doesn't allow us to talk publicly about potential developments in that version.

Share this post


Link to post

If I'm not mistaken, nothing can be publicly distributed that is developed with the Beta stage environment. And on the other hand, until it becomes public (ie sold publicly by Embarcadero) it doesn't make much sense to do anything. Any features could change at the last moment and therefore frustrate the work done (as well as producing unusable libraries).

Share this post


Link to post

If you have access to the beta, you can still prepare libs for its release - but you cannot publish / make available the libs.

Share this post


Link to post

Component libraries can be published that have been tested on beta versions, provided they don't reveal any features of the beta or use any new features.

 

The latest ICS v9 release has packages for Delphi 12, but did not need any changes for D12 other than VER360.   Several other libraries are also available from GetIt for the beta. 

 

Angus

 

Share this post


Link to post
10 minutes ago, Fr0sT.Brutal said:

This package madness really bothers. Especially knowing most versions doesn't differ at all.

I like the VirtualTreeeView approach, which has a package folder named RAD Studio 10.4+. It works perfectly for 11 and probably for 12, too.

Share this post


Link to post
3 minutes ago, Uwe Raabe said:

I like the VirtualTreeeView approach, which has a package folder named RAD Studio 10.4+. It works perfectly for 11 and probably for 12, too.

Yeah, nice, they did it right. I think every lib dev should do the same, and probably shrink some older packages like f.i. "XE2-XE8"

  • Like 1

Share this post


Link to post
1 hour ago, Fr0sT.Brutal said:

Yeah, nice, they did it right. I think every lib dev should do the same, and probably shrink some older packages like f.i. "XE2-XE8"

As one of the few lib devs that actually test their code on all supported Delphi versions I object - dproj files so often have incompatibilities in them.

Yes, it is possible to have only multiple dproj files but only one dpk they refer to and put the libsuffix stuff into an inc file referencing that one on the dpr (have done that, works fine) but it is tedious.

I rather copy the latest version when a new one comes out/is in beta.

 

The more important thing imo is using forward-compatible defines in the code - it drives me mad whenever I compile some code in a newer version and it simply does not work because the code requires explicit defines because they are not done in a forward-compatible way.

  • Like 6

Share this post


Link to post
1 hour ago, Stefan Glienke said:

The more important thing imo is using forward-compatible defines in the code

Agreed, guilty as charged. I've been modifying the inc files in my projects over the last few days.. mostly so they will be compatible with D12 without me having to do anything when it's released (unless they introduce breaking changes). 

I too prefer packages for each compiler versions - I have had too many issues over the years with the IDE messing up package upgrades and then not being able to compile - usually fixed by deleting the dproj and creating a new one. 

  • Like 1

Share this post


Link to post
1 hour ago, Stefan Glienke said:

I rather copy the latest version when a new one comes out/is in beta.

Me too. Although f.i. PngComponents are prepared to compile with newer versions without changing more than the LIBSUFFIX (which in my case is handled by Project Magician), I always copy the package folder to a decent named one.

 

The VirtualTreeView approach works fine when you just compile and install from the lowest Delphi version to the highest or you revert any changes before opening the package in another one.

 

Share this post


Link to post

I get the points raised.

But if you are in not under NDA, making a guess what defines you might need to tweak into .inc file or put into the package, can't violate the NDA. 

If you are under NDA and just publish packages and/or project files etc, Emba would shoot them self to the foot if they would enforce it in that case, IMHO. But seen stupider things done, so never know 😄

Problem of the NDA is, I assume, that you can't even ask for help, from  lets say, how to add D12 support for the Jcl. But I might be cunning and ask how did you make support for the D11,x And try to duplicate the process.

 

And this is kind of funny, because everyone knows few people that has D12 beta, and are under NDA most likely. And Embarcadero it self leaks that information. But person can't say anything and has to dance around. I understand that there must be some kind of limitations under beta, but making things too tight sure puts everyone in beta in  position that they have to do more work that they should. Also most likely can't test everything that they would like to, But this is just pointless rambling because it will not affect the company policy for sure...

-Tee-

 

 

  • Like 1

Share this post


Link to post

It is no secret that many or most components developers are beta testers under NDA, how else are all their components ready for each new release, or in the olde days on the component companion CD included with the final release.

 

This benefits everyone involved, because new versions of Delphi can be used for old projects immediately, rather than waiting weeks for developers to buy the new version, etc.

 

What has changed in recent years is beta testing being offered openly for paying customers, rather than by invitation only, and blogging about the next release, so it is now all more obvious.

 

Angus

 

 

 

  • Like 1

Share this post


Link to post
12 hours ago, Angus Robertson said:

The latest ICS v9 release has packages for Delphi 12, but did not need any changes for D12 other than VER360.

Please stop using VERxxx. It's been possible to do {$if CompilerVersion >= XX} since Delphi 6 or 7.

It's so annoying having to edit the .inc files of various 3rd party libraries with each new version of Delphi because they're designed as if the latest version = the last version.

 

 

10 hours ago, Stefan Glienke said:

As one of the few lib devs that actually test their code on all supported Delphi versions I object - dproj files so often have incompatibilities in them.

Yes, it is possible to have only multiple dproj files but only one dpk they refer to and put the libsuffix stuff into an inc file referencing that one on the dpr (have done that, works fine) but it is tedious.

I rather copy the latest version when a new one comes out/is in beta.

Graphics.32 uses {$LIBSUFFIX AUTO} for the D11+ packages. The earlier packages are manually maintained by using a diff tool to keep them synchronized with a master. The master usually comes from the latest supported Delphi version.

There's no way I'm wasting disk space on old versions of Delphi just to maintain the package files. I have the latest version, and the few versions required by my job, and that's it.

  • Like 4

Share this post


Link to post

Was just thinking,

 

Can anyone figure out why Embarcadero could/would/should not publish rtl, compiler etc versions and codename for the beta, just as they include first outsider to the beta test?
 

Those things are not that big of an secret. or allow publishing trivial work done with beta versions. Like the packages or support for IDE plugins (with some limitations maybe??).

 

-Tee-

Share this post


Link to post
10 hours ago, Anders Melander said:

It's been possible to do {$if CompilerVersion >= XX} since Delphi 6 or 7.

It was introduced with Delphi 6.

Share this post


Link to post
3 hours ago, Tommi Prami said:

Can anyone figure out why Embarcadero could/would/should not publish rtl, compiler etc versions and codename for the beta, just as they include first outsider to the beta test?

 

Those things are not that big of an secret.

That would make it harder to detect breaches of the NDA and start arguments about where the limits are. It's much easier to forbid any mention.

  • Like 1

Share this post


Link to post
11 hours ago, Anders Melander said:

Please stop using VERxxx. It's been possible to do {$if CompilerVersion >= XX} since Delphi 6 or 7.

It's so annoying having to edit the .inc files of various 3rd party libraries with each new version of Delphi because they're designed as if the latest version = the last version.

I'm completely with you here and I even created my own compiler version/capabilities include file. BUT. $IF's are not recognized by IDE at code-time. Still after 20+ years it breaks on every $IF. That is annoying

Share this post


Link to post
32 minutes ago, Fr0sT.Brutal said:

BUT. $IF's are not recognized by IDE at code-time. Still after 20+ years it breaks on every $IF. That is annoying

Works for me:

image.thumb.png.3926477ba8f167c713d64a6ac38fddb8.png

  • Like 2

Share this post


Link to post
1 hour ago, dummzeuch said:

It was introduced with Delphi 6.

You can even check for it:

{$IFDEF CONDITIONALEXPRESSIONS}
{$IF CompilerVersion < 23.0}
  ...
{$IFEND}
{$ENDIF}

 

Share this post


Link to post
4 hours ago, Tommi Prami said:

Can anyone figure out why Embarcadero could/would/should not publish rtl, compiler etc versions and codename for the beta, just as they include first outsider to the beta test?

For the same reason they have ridiculous NDAs and don't have public betas; They are so stuck in the 90s that they think anyone still gives a damn.n They never understood how to build a community.

  • Like 5

Share this post


Link to post
9 minutes ago, Uwe Raabe said:

You can even check for it:


{$IFDEF CONDITIONALEXPRESSIONS}
{$IF CompilerVersion < 23.0}
  ...
{$IFEND}
{$ENDIF}

 

So, can anyone remember which version of Delphi broke that scheme?

 

It's not broken now, but I'm certain that there was a version after Delphi 6 that somehow broke {$IF} so it couldn't be used if backward and forward compatibility was needed.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×