Hi,
Thanks for the nice words!
The Binary packages thing has actually been available for a while, most tms trials are done with it, and also TMS WebCore is a binary distribution. You can see an example yourself for example if you go and install a FlexCel trial, or TMS webcore. (note that the trials are setup.exe files, but inside, they just have a smartsetup bundle and tms.exe itself. All the setup does is to run tms.exe in the bundle, and if you run the installer, you will end up with a smartsetup install).
So, how do binary projects work? The same as source projects work 
Let's see the FlexCel example. If this was a source distribution, tms would find the file tmsbuild.yaml inside a folder, and see inside this text (among other stuff):
packages:
- FlexCel_Core: [runtime, vcl, fmx, skia]
- FlexCel_XlsAdapter: [runtime, vcl, fmx, skia]
- FlexCel_Pdf: [runtime, vcl, fmx, skia]
- FlexCel_Render: [runtime, vcl, fmx, skia]
...
So now, with that information, smartsetup will go and search for FlexCel_Core.dproj, or FlexCel_Core.lpk, or a list of possible extensions (for all the compilers we support), until it finds a project FlexCel_Core.something that it knows how to compile.
Once it finds say FlexCel_Core.dproj, it will compile it and it will generate the dcus and binaries in a folder like R:\smartsetup\Products\tms.flexcel.vcl\Packages\d12+\37.0\Win32\Release. Then it will register those files, etc.
That is basically the workflow. For binary distributions, the original idea was to put the binaries directly in R:\smartsetup\Products\tms.flexcel.vcl\Packages\d12+\37.0\Win32\Release, skip the compilation phase, and just register them. I tried this approach like for a week, and beside the fact that it was ugly code, full of "if IsBinary then... else...", there were some cases that we just couldn't handle. SmartSetup was designed to know R:\smartsetup\Products\tms.flexcel.vcl\Packages\d12+\37.0\Win32\Release is full of generated files, and it can (and does) delete them when it wants to. So again another thousand if IsBinary then don't delete.... until we realized that you could mix binary and not binary packages, and those if wouldn't even work. They should delete the folder for the source packages, but should not delete the same folder because of binary packages.
We had to come back to the drawing board, and we came up with a different solution that
- doesn't add a single if IsBinary to the code
- can mix source and binary packages without issues.
And the solution was to create a "fake" compiler that would compile source dcus into the same dcus, just by copying them (actually linking them to avoid having the file twice). You know, a Delphi compiler takes the source .pas files and uses to generate dcus in R:\smartsetup\Products\tms.flexcel.vcl\Packages\d12+\37.0\Win32\Release. You can delete R:\smartsetup\Products\tms.flexcel.vcl\Packages\d12+\37.0\Win32\Release because you can regenerate it from the sources. A lazarus compiler will do the same from the files in a lpk. And we already had a pluggable system where we could add new compilers.
So, this binary "compiler" works exactly the same as the others, but instead of compiling .pas into dcus, it just copies the dcus from the source to R:\smartsetup\Products\tms.flexcel.vcl\Packages\d12+\37.0\Win32\Release. You can now delete that folder as usual, and it can be regenerated from the "source" dcus.
To complete the system, this new compiler needs a "project" so tms.exe can find it when it searches for FlexCel_Core.something as said above. Delphi uses .dproj as ".something" for packages, and we use .binproj for our compiler.
binprojs are actually empty, they just need to exists so the pluggable compiler system in tms can detect a file it has to compile, and call the compiler associated with binprojs. In a more "correct" world, the binproj would have inside all the source files it needs to "compile", same as a dproj. We might still do that in the future, but for now, if the binproj is empty, we just have a convention that when the binproj is empty, the "sources" are in R:\smartsetup\Products\tms.flexcel.vcl\BinPackages
The binary compiler won't actually read what is in the empty binproj, but just link all that is in \BinPackages to \Packages and that is it.
So, in short, to create a new binary distro:
- For every .dproj in your source distro, replace it with an empty .binproj file. If you don't have any source packages, just create one per bpl, with the same names. If you have MyPack.bpl, you need a MyPack.binproj2.
- In tmsbuild.yaml,
packages section, list every binproj file as one package
- In
\BinPackages, dump all the stuff you want to copy to \Packages
As said you might find it simpler to see if you install one of our trials and look how they work. In FlexCel for example:
-
In \Packages, we have (look how all the binprojs are 0 bytes):
-
In tmsbuild.yaml, we have:
packages:
- FlexCel_Core: [runtime, vcl, fmx, skia]
- FlexCel_XlsAdapter: [runtime, vcl, fmx, skia]
- FlexCel_Pdf: [runtime, vcl, fmx, skia]
- FlexCel_Render: [runtime, vcl, fmx, skia]
- FlexCel_Report: [runtime, vcl, fmx, skia]
- VCL_FlexCel_Core: [runtime, vcl]
- FMX_FlexCel_Core: [runtime, fmx]
- FMX_FlexCel_Components: [runtime, fmx]
- FMX_FlexCel_Components_DESIGN: [design, fmx]
- SKIA_FlexCel_Core: [runtime, skia]
- VCL_FlexCel_Components: [runtime, vcl]
- VCL_FlexCel_Components_DESIGN: [design, vcl]
- And in \BinPackages, we have the "source" binaries:
Well, that is basically it. Put your binaries in \BinPackages, create a .binproj for every package file in tmsbuild.yaml, and smartsetup will link whatever you put in \BinPackages to \Packages when it installs. It will then register, for every package.binproj you have, the binproj,dll in the IDE.
As balise pascal said, sorry I didn't had the time to make this post shorter We are just coming back from tms days and we have a lot of mails to answer... but I hope the post came clear enough. Don't hesitate to ask for clarification in anything that wasn't.
