Vincent Parrett

Using conditionals compilation in a dpk or dpr is problematic - the IDE does not handle it well.

That's intersting, I tried it today and it didn't work, not sure what I did wrong but will try it again. There is another property for dll's - OutputExt (in the dproj) - in the IDE it's called "Target file extension" - for dcc32 it needs a command line option. Not sure when it was introduced, need to investigate for finalbuilder. Thanks.

DLL projects do not support LibSuffix, so if you want to generate dll's with a different naming convention (with the default being the same for every dproj) - how do you do that if you are just copying a single dproj. Sure you can do that during the copy/generation of the projects if you code it, but where do you configure that (rather than hard coded in the generator)? BTW, I can no longer see UweRaabe/PackageMagician on github?

ok, perhaps it's just me that needs that.

looking through my projects on github - I found one example so far - I need to change the name of the project and output dll for expert dll's - if I'm just rehashing a single dproj then where do I configure that?

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.