Vincent Parrett

I don't have a concrete example to hand. So perhaps it is just a gut feeling.

Simply adding or changing the units or resources that need to be included in a dproj for specific compiler versions. Or compiler options for that matter - delphi is not without it's issues that needs work arounds.

My issue with this is that it's not uncommon for the units etc to differ between platforms. If we use the latest version and just copy that then any customisations you need to make to a particular version would be lost each time you generate the packages.

Yeah I understand! I really wasn't planning on working on this, but I realised after reading this thread that it was a major pain point on my OS projects. Thanks, that's useful to know. I've only gone as far back as XE2 as that's the earliest version I have installed or support in my projects.

@Uwe Raabe are you interested in helping out with this project (since you are the dproj wizard!) - https://github.com/VSoftTechnologies/DPackGen The idea is to create a definition file which can be used with the tool to generate dpk/dpr/dproj files for the supported delphi versions - something that pretty much all delphi library authors struggle with (add one file, edit 50 files to add that one file!). I have the basics working - dproj generation is somewhat iffy as I need to figure out all the differences in the various dproj versions. Also need to flesh it out with more properties etc in the definition file.

I did end up using JSON - simply because it's easier to parse I have made a start on this - https://github.com/VSoftTechnologies/DPackGen Example definition file. It's modelled on how I did the package spec files for my packag manager project (which I really need to get back to!) - so I was able to copy/pasta a lot of the code or at least borrow the design of the definition parsing and package generation. Supporting XE2-11.x I uses templates, you can define more than one if a compiler version needs different settings. I might also look at allowing templates to inherit from another template, so if a template only needs to change a few settings it can be a bit less verbose. Note that you don't have to use the template, you can define all the settings on the targetPlatform - just remove the template property and fill in the rest of the props like in the template - but using templates reduces verbosity. { definitionSchemaVersion: 0, name : "VSoft.MessagingR", packagesFolder: ".\\packages", projectGUID: "{8FF7EA44-009F-4370-BDA2-3C30D26F6FC9}", frameworkType : "VCL", packageType : "Runtime", targetPlatforms : [ { compiler : "XE2", platforms : "Win32, Win64", template : "default" }, { compiler : "XE3", platforms : "Win32, Win64", template : "default" }, { compiler : "XE4", platforms : "Win32, Win64", template : "default" }, { compiler : "XE5", platforms : "Win32, Win64", template : "default" }, { compiler : "XE6", platforms : "Win32, Win64", template : "default" }, { compiler : "XE7", platforms : "Win32, Win64", template : "default" }, { compiler : "XE8", platforms : "Win32, Win64", template : "default" }, { compiler : "D10.0", platforms : "Win32, Win64", template : "default" }, { compiler : "D10.1", platforms : "Win32, Win64", template : "default" }, { compiler : "D10.2", platforms : "Win32, Win64", template : "default" }, { compiler : "D10.3", platforms : "Win32, Win64", template : "default" }, { compiler : "D10.4", platforms : "Win32, Win64", template : "default" }, { compiler : "D11", platforms : "Win32, Win64", template : "default", libSuffix : "%compilerVersion%" } ], templates : [ { name : "default", libSuffix : "%compilerVersion%", folderNameTemplate: "Rad Studio %Compiler% %CompilerCodeName%", descriptionTemplate: "VSoft.Messaging Runtime for Delphi %Compiler%", files : [ ".\\src\\VSoft.Messaging.pas", ".\\src\\VSoft.Messaging.Internal.pas", ".\\src\\VSoft.Messaging.Dispatchers.pas", ".\\src\\VSoft.Messaging.Channel.pas" ], requires : [ "rtl" ], dpkOptions: [ "{$R *.res}", "{$IFDEF IMPLICITBUILDING This IFDEF should not be used by users}", "{$ALIGN 8}", "{$ASSERTIONS ON}", "{$BOOLEVAL OFF}", "{$DEBUGINFO ON}", "{$EXTENDEDSYNTAX ON}", "{$IMPORTEDDATA ON}", "{$IOCHECKS ON}", "{$LOCALSYMBOLS ON}", "{$LONGSTRINGS ON}", "{$OPENSTRINGS ON}", "{$OPTIMIZATION OFF}", "{$OVERFLOWCHECKS OFF}", "{$RANGECHECKS OFF}", "{$REFERENCEINFO ON}", "{$SAFEDIVIDE OFF}", "{$STACKFRAMES ON}", "{$TYPEDADDRESS OFF}", "{$VARSTRINGCHECKS ON}", "{$WRITEABLECONST OFF}", "{$MINENUMSIZE 1}", "{$IMAGEBASE $400000}", "{$DEFINE DEBUG}", "{$ENDIF IMPLICITBUILDING}", "{$DESCRIPTION '%description%'}", "{$LIBSUFFIX '%LIBSUFFIX%'}", "{$RUNONLY}", "{$IMPLICITBUILD OFF}" ] } ] } I used my package manager to install the dependencies (JsonDataObjects, Spring4D.Base & VSoft.CommandLineParser) so if you want to build it you would need to grab those projects from github/bitbucket and update the search paths. DPK generation mostly works - need to figure out how to deal with forms/frames. DPROJ generation is a work in progress - not there yet - the dproj format is not trivial to generate due to config inheritance etc. Hopefully I will find some time over the weekend to work on it and get it to a usable state. I need to flesh out the properties for the TargetPlatform/Template for things like search paths, namespace prefixes, output paths etc. BTW I have not made any provisions for generating CBuilder packages - I guess that can come later if someone wants to work on it - I don't have a need for it so not likely to do it myself.

The cool thing about generating the dproj files from scratch (rather than using a template) is we don't need to generate a lot of the sh1te that rad studio does. Using templates would be tricky due to the differences between delphi releases. So I'm not keen on templates as such. More likely I will implement this in dpm itself.. as a dpm package could have more than one delphi package (dpk) in it. There is already a stubbed out dpm spec command

Actually it's probably not that much work to create a package generator - the hardest part will be creating the definition schema. Something like this (YAML) schemaVersion: 0.1 package: name: VSoft.MessagingR compilerVersions: XE2-11 libSuffix: %compilerVersion% packagesFolder: .\packages folder-template: Rad Studio %ProductVersion% %CodeName% platforms : Win32, Win64 files: - .\src\VSoft.Messaging.pas - .\src\VSoft.Messaging.Internal.pas - .\src\VSoft.Messaging.Dispatchers.pas - .\src\VSoft.Messaging.Channel.pas requires: - rtl compilerOptions : | {$R *.res} {$IFDEF IMPLICITBUILDING This IFDEF should not be used by users} {$ALIGN 8} {$ASSERTIONS ON} {$BOOLEVAL OFF} {$DEBUGINFO ON} {$EXTENDEDSYNTAX ON} {$IMPORTEDDATA ON} {$IOCHECKS ON} {$LOCALSYMBOLS ON} {$LONGSTRINGS ON} {$OPENSTRINGS ON} {$OPTIMIZATION OFF} {$OVERFLOWCHECKS OFF} {$RANGECHECKS OFF} {$REFERENCEINFO ON} {$SAFEDIVIDE OFF} {$STACKFRAMES ON} {$TYPEDADDRESS OFF} {$VARSTRINGCHECKS ON} {$WRITEABLECONST OFF} {$MINENUMSIZE 1} {$IMAGEBASE $400000} {$DEFINE DEBUG} {$ENDIF IMPLICITBUILDING} {$DESCRIPTION 'VSoft.Messaging Runtime for %ProductVersion%'} {$LIBSUFFIX '%LIBSUFFIX%'} {$RUNONLY} {$IMPLICITBUILD OFF} The idea being there would be a bunch of built in variables like CompilerVersion, ProductVersion etc that can be sprinkled in the template and then replaced when the dproj/dpk files are generated. Obviously there is more to add to the above, like output folders, configs etc.. but it should be pretty simple to build on it. I'll make a start and chuck it up on github, open to suggestions on the definition schema. I'll probably use https://github.com/neslib/Neslib.Yaml for the yaml parser (haven't tried it yet though).

This is something I have thought about doing - managing package files for multiple compiler versions is really tiresome. The dproj format has evolved a bit over the years.. but it shoud still be doable. A command line tool that takes in a definition file and spits out the dpk and dproj would be pretty awesome. I should have some free time in 2036 to actually do it🙄

Ah ok, I misread their site - was looking at this page - https://about.gitlab.com/solutions/open-source/join/ Didn't realise that was for the full version of gitlab.

Much simpler to switch to github, for gitlab you have to apply for free hosting of open source.

I use generics a lot in non container/collection scenarios - for example Delphi Mocks fluent api uses the generic type to allow a type safe definition of the mock. Without generics we would be using strings - which is not typesafe and would not survive refactoring. Another example - I have lexer/parser library (used in FinalBuilder) //NOTE : T MUST be an Enumerated Type (need better constraints!) TTokenRec<T> = record private ..... end; ILexer<T> = interface function Next : TTokenRec<T>; ... TBaseLexer<T> = class(TInterfacedObject,ILexer<T>) //concrete usages TDSLLexer = class(TBaseLexer<TDSLTokenKind>,IDSLLexer) TVariableSenseLexer = class(TBaseLexer<TTokenKind>) //parsers built on top of the lexers IParser<TAstNodeType,TParseErrorType> = interface TBaseParser<TTokenType,TAstNodeType,TParseErrorType> = class(TInterfacedObject,IParser<TAstNodeType,TParseErrorType>) TDSLParser = class(TBaseParser<TDSLTokenKind,TDSLASTNodeType,TDSLParserErrorType>) TVariableSenseParser = class (TBaseParser<TTokenKind, TVariableSenseASTNodeType, TVariableSenseParserErrorType>) Generics allows you to avoid copying and pasting tons of boilerplate code, changing types etc, or doing having to do tons of nasty type casting. If Delphi's generics were better there would be many more uses for them, but when you attempt anything complex you run into limitations. If you really want to know what else can be done with generics, you would have to look at other languages that have better generics implementations (like c#).

Hi All I recently did a presentation to the Australian Delphi User Group (ADUG) over zoom - the presentation was recorded and uploaded to youtube - thought it might be worth sharing here 😉 I talked a bit about devops in general, then Continuous Integration and Automated Builds, before showing Continua CI using MSBuild (and a bit of FinalBuilder), running a build, running unit tests etc.

Not sure C++ builder would save you any time, most c++ libraries do not compile with c++ builder, and c++ builder doesn't support all the platforms that delphi does (missing android).

https://www.finalbuilder.com/resources/blogs/code-signing-with-usb-tokens

I didn't have any issues with that last time.. but that was 3 yrs ago. I'm sure these dongles will be a nice little earner for thales and the CA's - the cost of certificates is already outrageous without the added expense of the dongle. CA's say the cost is for the time spent validating the applicants - my guess is much of that is automated - and they have minimum wage call centers doing the rest. License to print money.

Thanks. One thing to bear in mind with usb is that it is very sensitve to latency - so not sure how it would work in high latency connections. I have fiber at home and get 6ms pings to the data center where our servers live - which is fine. I suspect anything over 30ms might be a problem for some devices.

Blogged - https://www.finalbuilder.com/resources/blogs/code-signing-with-usb-tokens

LOL - no. There is - you create a certificate request which you send to the CA - they send back a certificate that can only be installed on the HSM that generated the certificate request. The CA websites do a really bad job at explaining things.

I hadn't seen that one, and based on what I have found out about it so far I'm just going to ignore it. Nice idea but will likely fail with hardware tokens - the private key stays on the token - so you need client software to allow the code signing tool to access it.

Yup, have to a gree, and it doesn't help that the sites that sell certificates are just plain sh1te - I've never seem so much unhelpful content in one place. Working on a blog post about this, hoping to get it out tonight (it's almost 8pm here) or tomorrow. I'm trying to edit it down to a reasonable size and reduce the jargon where possible.

Good luck doing that when your build process runs from a windows service where you are not logged in.

I suspect this would be wasted money - my guess is OV certificates will eventually be discontinued.

I have been researching this for some time, since it will impact most of our customers. I really do wonder if they have considered the impact this will have on build automation. One thing I would point out is do not get a certificate that is issued on a Yubikey - there is absolutely zero way to automate signing - the yubikey uses the windows smart card api and absolutely prompts on every file you sign! So far in my research, it seems only SSL.com (also the cheapest) use Yubikeys - everyone else I have looked at so far uses SafeNet tokens, which do have a work around. If anyone has a token other than SafeNet or Yuibkey please let me know (brand and where it was issued). I did buy a Yubikey (without a cert) to experiment with but didn't get far with that yet. https://www.finalbuilder.com/forums/t/signtool-with-ev-certificate-fails/6535/22 I have yet to confirm if this work around works from a windows service (which is typically how CI servers run). More testing to be done in the next few days before my EV cert expires (we are still using our OV cert that expires next year in production).

Routing a support/install/licensing issue to sales (often 5 different people) to try and strong arm you into paying money doesn't make it a sales issue. I don't know of any other software company that sells perpetual licenses that does this. I've had issues installing old software before, but never once have I been strongarmed to buy again like embarcadero does. Hell, I sell software, and if you came to me an told me you had lost your v1 license key from 2001 I would help you get it installed at no charge (this happens multiple times a week). Of course I might suggest that you upgrade (and even offer a discount to get you on board), but I'm not going to route you to different people or employ used car sales tactics to get you to upgrade, I'll make the offer while helping you. Embarcadero need to do better if they want to retain customers and get old customers back on board, because right now their tactics are driving people away.