Blogged : Advice for Delphi library authors

[Vincent Parrett 763]

https://www.finalbuilder.com/resources/blogs/advice-for-delphi-library-authors

[Uwe Raabe 2064]

Meanwhile a bit dusty, but most of it is still valid and overlaps your suggestions nicely: Delphi Library Guidelines

[dummzeuch 1517]

1 hour ago, Vincent Parrett said:

https://www.finalbuilder.com/resources/blogs/advice-for-delphi-library-authors

Unfortunately many well known commercial and open source libraries don't adhere to these. It's a major pain in the lower back every time I want to install Delphi on a new computer (which happens quite regularly, at least several times per year).

[Lars Fosdal 1793]

Name them and shame them into adherence!

I am only half-kidding...

[dummzeuch 1517]

11 minutes ago, Lars Fosdal said:

Name them and shame them into adherence!

I am only half-kidding...

Actually I did less than a year ago:

Compiling TeeChart 2020 for Delphi 2007

Quote

You don’t really hard code the package suffixes into the project file names! That was only necessary until Delphi 5.

 

Guess who has hard coded project suffixes too? TeeChart does: 911 for Delphi 2007 which means TeeChart version 9 for Delphi 11. That’s not even the standard suffix which would have been 110.

It won't help, of course.

[Fr0sT.Brutal 900]

2 hours ago, Vincent Parrett said:

https://www.finalbuilder.com/resources/blogs/advice-for-delphi-library-authors

Package Names

I guess many projects don't even require personal package files for every Delphi version. Not talking about DPK files which mainly are the same.

Use Search Paths for includes

Tend to disagree. This makes package files obligatory while otherwise they're optional. Moreover, you won't be able to explore that include file from unit code unless you loaded the package project. What's wrong with relational paths?

[David Champion 48]

What about LIB suffix $(Auto) does that conform to your guidelines?

[balabuev 102]

Use Explicit rebuild, not Rebuild as needed

I will consider this one...

[mvanrijnen 123]

1 hour ago, David Champion said:

What about LIB suffix $(Auto) does that conform to your guidelines?

$(Auto) exists? where can i find things like this? 

 

[Uwe Raabe 2064]

1 hour ago, mvanrijnen said:

$(Auto) exists? where can i find things like this? 

It was introduced in 10.4 Sydney - Release 1

[dummzeuch 1517]

1 hour ago, mvanrijnen said:

$(Auto) exists? where can i find things like this?

If I remember correctly, it was added in Delphi 10.4, so it won't help much if you develop for multiple Delphi versions.

[Uwe Raabe 2064]

If it is the only change in the project files, it would at least work for packages 10.4 and up - at least until any new setting throws a spanner into the gear.

[Vincent Parrett 763]

5 hours ago, David Champion said:

What about LIB suffix $(Auto) does that conform to your guidelines?

Yes, I forgot about that feature. I have updated the post to mention it. 

[Vincent Parrett 763]

8 hours ago, dummzeuch said:

Unfortunately many well known commercial and open source libraries don't adhere to these. It's a major pain in the lower back every time I want to install Delphi on a new computer (which happens quite regularly, at least several times per year).

Agreed, that's what gave me the idea to write the post 😉

[Vincent Parrett 763]

6 hours ago, Fr0sT.Brutal said:

Tend to disagree. This makes package files obligatory while otherwise they're optional. Moreover, you won't be able to explore that include file from unit code unless you loaded the package project. What's wrong with relational paths?

Well I am talking mostly about packages in the post, so in that context it makes sense. 

 

Relative paths are fine, until one of the files moves around. I had that issue yesterday with a well known third party package that wouldn't compile.. the relative paths on the includes were wrong. 

[Vincent Parrett 763]

6 hours ago, Fr0sT.Brutal said:

Package Names

I guess many projects don't even require personal package files for every Delphi version. Not talking about DPK files which mainly are the same.

If the library is just a simple few pas files and doesn't have any design time components then yes, packages are not needed.  That said, there are still benefits to providing packages, as it allows the libraries to be compiled and you can then just reference the compiled library files (dcu's) instead of compiling the library every time you build. I recently implemented this in my package manager project and it cut the build time (for 12 delphi versions) from 13 minutes down to 1 or 2 minutes for the package manager projects (command line tool plus ide plugins). 

[Bill Meyer 337]

Also, as far as I know, many (most?) component packages ignore the possibility of "Install for All Users." Some claim (falsely) to support it. 

 

Not usually an issue, but some months ago, I was setting up a new VM to be used by members of our team, and it would have been convenient to install the 8 devs as users, then install everything to be for all users. Each could then make the VM personal by removing the other users.

[Remy Lebeau 1436]

13 hours ago, dummzeuch said:

Actually I did less than a year ago:

Compiling TeeChart 2020 for Delphi 2007

Despite the title, that post is shaming Indy much more than it does TeeChart.  And at the end, it says:

Quote

But those indy guys seem to be kind of sloppy.

I'm well aware of the issues you raised in that post.  OK granted, the .bat scripts are a bit of a mess (I never use them myself, and the only reason they even exist is for supporting C++Builder).  But the package names having hard-coded suffixes is not about being sloppy, it is about backwards compatibility.  Indy still supports all the way back to Delphi 5 and even 4, which predate the LIBSUFFIX option.  And by the time LIBSUFFIX actually became commonly used by component authors, it was too late to update Indy 10 without major breakages in existing user code.  There is an open ticket to add LIBSUFFIX support to Indy, which is scheduled to be implemented in Indy 11, when support for old compilers will be dropped.

 

Frankly, I don't know why TeeChart was ever referencing IndyProtocols.dcp in the first place, since Indy has NEVER used non-suffixed package names.  IIRC, it might have been CodeGear/Embarcadero that did, at one time, strip off the suffixes in their private copies of Indy that shipped with the IDE.  But the official version of Indy has ALWAYS used suffixed package names.

[Vincent Parrett 763]

1 hour ago, Remy Lebeau said:

Frankly, I don't know why TeeChart was ever referencing IndyProtocols.dcp in the first place, since Indy has NEVER used non-suffixed package names.

LIBSUFFIX doesn't affect the dcp file names, only the bpl. 

 

I have to say that I wish Embarcadero were not shipping Indy so intertwined with the product. Pretty much the first thing I do when installing Delphi is remove all traces of Indy so that I can install my own version (usually later than the one they ship).  

[Fr0sT.Brutal 900]

10 hours ago, Vincent Parrett said:

Relative paths are fine, until one of the files moves around. I had that issue yesterday with a well known third party package that wouldn't compile.. the relative paths on the includes were wrong. 

Hmm, wasn't that a mistake in that package? And how did it happen, its dev didn't try to build it?

10 hours ago, Vincent Parrett said:

If the library is just a simple few pas files and doesn't have any design time components then yes, packages are not needed.  That said, there are still benefits to providing packages, as it allows the libraries to be compiled and you can then just reference the compiled library files (dcu's) instead of compiling the library every time you build

Not exactly what I was talking about. Packages are good, but in many cases personal package project files for every version are excess. Delphi has pretty cool compatibility with older versions so one project file for all XEs should be enough (honestly I just dislike all those huge listings of <name>_D<whatever>.dproj files that are completely identical in fact).

10 hours ago, Bill Meyer said:

Also, as far as I know, many (most?) component packages ignore the possibility of "Install for All Users." Some claim (falsely) to support it. 

IMHO component packages should not bother about installation process at all. Let IDE decide how and where to build them! There are plenty of libs that suggest to install themselves in Program files, or C:\, or %APPDATA%, or %ALLUSERSPROFILE%... sometimes they don't even ask for path and silently install where they decide!

My opinion here: custom installers for component libs are evil.

3 hours ago, Vincent Parrett said:

I have to say that I wish Embarcadero were not shipping Indy so intertwined with the product. Pretty much the first thing I do when installing Delphi is remove all traces of Indy so that I can install my own version (usually later than the one they ship). 

Doesn't upgrade from GetIt solve this issue?

Edited February 25, 2021 by Fr0sT.Brutal

[dummzeuch 1517]

4 hours ago, Remy Lebeau said:

granted, the .bat scripts are a bit of a mess

I offered to help out and even submitted pull requests with updates for them, but they were ignored for several months. Then I gave up.

[mvanrijnen 123]

13 hours ago, dummzeuch said:

If I remember correctly, it was added in Delphi 10.4, so it won't help much if you develop for multiple Delphi versions.

Where is this documented, i search a couple of times where these things are documented but could not find anything at embarcadero.

 

[Vincent Parrett 763]

46 minutes ago, Fr0sT.Brutal said:

Doesn't upgrade from GetIt solve this issue?

Umm.. Getit solves very little of anything I'm afraid. 

[Fr0sT.Brutal 900]

32 minutes ago, Vincent Parrett said:

Umm.. Getit solves very little of anything I'm afraid. 

Pity. I thought it was intended for such cases

[timfrost 79]

In the Webinar yesterday, responding to a question about compiler updates/upgrades, I heard Marco say that 'Getit is a bit of a problem because it always uninstalls the old version before installing'. How can anyone defend this approach? What happens when you test the new version and something fails to work?  Where is the old source code for you to compare the differences and either fix them or adjust your usage?  A component installer should never force an install into the location of the production library; it should always be checked and validated before it is too late to do this.