Compiler/Platforms

[vincentparrett]

Packages need to specify which versions of delphi, and which platforms (windows, macos, linux etc) they support. There is also the issue of binary compatibility between compiler updates (will need to define the rules for this as updates are released).

My intention is to specify this with a TargetPlatform type, which has 3 parts, which can be expressed as a string, and easily parsed. Update level is expressed as an integer (0-10, noting that there have never been 10 updates for a compiler version), or a for any update level.

The form would be CompilerVersion.UpdateLevel.Platform

Examples

  DelphiXE7.1.Win64
  Delphi10Berlin.1.iOS32
  Delphi10Tokyo.3.Linux64
  Delphi10Tokyo.0.Win32

Type definitions :

TDPMCompilerVersion = (
  InvalidVersion,
  Delphi2009,
  Delphi2010,
  DelphiXE,
  DelphiXE2,
  DelphiXE3,
  DelphiXE4,
  DelphiXE5,
  DelphiXE6,
  DelphiXE7,
  DelphiXE8,
  Delphi10Seattle,
  Delphi10Berlin,
  Delphi10Tokyo
);

TDPMCompilerVersions = set of TDPMCompilerVersion;

//covering all bases here.
TDPMPlatform = (
  InvalidPlatform,
  Win32,
  Win64,
  MacOS32,
  MacOS64,       //reserved for future use
  Android,        //arm chip
  AndroidIntel32, //reserved for future use
  AndroidIntel64, //reserved for future use
  iOS32,
  iOS64,        //reserved for future use
  LinuxIntel32, //reserved for future use
  LinuxIntel64,
  LinuxArm32,   //reserved for future use
  LinuxArm64   //reserved for future use
  );

TDPMPlatforms = set of TDPMPlatform;

TDPMUpdateLevel = (
  RTM,
  Update1,
  Update2,
  Update3,
  Update4,
  Update5,
  Update6,
  Update7,
  Update8,
  Update9,
  Update10, //optomistic, don't think there has ever been this many updates.
  Any = 999
  );

[jkour]

In the TDPMPlatofrm the Android word is misspelled

[jkour]

I don't know how you plan to use the versioning system you propose (CompilerVersion.UpdateLevel.Platform) but if some form of sorting evolves from this maybe it is better to reverse the platform and update level. This way all packages for a specific platform will be grouped together

But now you can argue that you group platforms per version. As said, it depends on the use

[vincentparrett]

I'm still working through this, hopefully when I publish what I have done (not much) it will be more obvious, I did this all a long time ago, and I'm still trying to figure out things again (it's like looking at someone else's code!).

[casteng]

Maybe it's worth to separate CPU target (i386, x64, arm32 etc) and OS target (Win, Linux, Android etc) as it's done in Free Pascal

[bogdanpolak]

@casteng:

Maybe it's worth to separate CPU target (i386, x64, arm32 etc) and OS target (Win, Linux, Android etc) as it's done in Free Pascal

Free Pascal should be treated totally differently: https://en.wikipedia.org/wiki/Free_Pascal#History For FP we've got: processor architecture x operating system x compiler version It could be too difficult to combine both in one Package Manager

[bogdanpolak]

@vincentparrett: about TDPMUpdateLevel. Is it really required? In my opinion newest update should be required. Maybe DPM should displaying warning when it will detect not updated version of Delphi compiler?

[casteng]

@bogdanpolak totally differently to what? the same fields have the same meaning for Delphi. and supporting FPC will add no additional problems except more possible variants for these fields. Which are just strings anyway. Dependency manager itself should not depend on compiler. There can be some tools for particular compiler or IDE. But in its core it's just managing packages and their dependencies. No relation to a compiler. No support of FPC is a mistake: many libraries support both FPC and Delphi and Object Pascal community is not so big to fragment it without a reason.

[vincentparrett]

@bogdanpolak I've seen situations where libraries will not compile with out a particular update applied. And for the most part dcu compatibility is maintained between updates, but that's not guaranteed.

With regards to FPC, I do not think it's worth considering in the first iteration. Most of the work is around package install, which is different between delphi and FPC. There are enough challenges to support as many Delphi versions as possible, without the added complexity of FPC.

[jcangas]

To identify IDE vs in my DelphiVM, I used the registry key "ProductVersion". It already determines de compiler version and binary compiler compatibility. It is the same number Delphi adds to their bpl files: vcl150.bpl and the like. So the TDPMUpdateLevel will not be necessary: if ProductVersionis the same you have binary compatibility. I added D or C in front of this number to means Delphi / C++. So you get package names like MyGreatPck-1.0.0+D250-Debug-Win32.zip.

I don't know about FPC, but maybe we can assign also a prefix and get something like MyGreatPck-1.0.0+FP320-Debug-Win32.zip.

Anyway, wee need first agree on the "segments" to build the full package filename

[jcangas]

I noted also you are not considering the Config segment (Debug, Release). Why? For large libs separate release from debug in 2 different packages can speed downloads.

[vincentparrett]

I'm not planning on separate packages for Debug and Release, so it's not part of the package version. My thought was all packages would be Release, but could ship optional Debug dcu's. The reality is most people don't need or use debug dcu's (at least that's been my experience, as a component developer and build tool developer). If the source is available then you don't need debug dcu's.

[jcangas]

I agree with general idea: be default pacakges, would be release. The point is: a package can contain dcu, dcp, dfm, res, bpl, dll and maybe .exe files. Include Debug files doubles the package size and download time. So allowing a separate Debug package maybe good feature for large libs, like SecureBlackBox, for example. But we can add this feature after first dpm releae, when will have real use experience