SmartSetup V3.3.0.0: Building C++Builder projects (*.cbproj)

Hi,

I am trying to follow the SmartSetup documentation about Using SmartSetup for CI automatic builds. However, I am using C++Builder and running tms spec complains about not being able to find any .dproj files. Trying to build any C++Builder .cbproj does not pick up anything, too.

Searching through the docs indicates that .cbproj projects are supported starting with V1.1.

Is there any chance you can take a look or provide a sample?

Thanks!

Hi,
C++ builder support is indeed under-baked, and yes, I know this is a sad reality for C++ builder users. In our case:

  • We don't have any C++ builder component at tms, and it is hard to find them in the open source world too. The reason in simple: If you create a Delphi component it can be used from both Delphi and C++ builder, but if you create a C++ component, it will only be usable from C++ builder. So people writing components tend to take the less effort approach, which is to code them in Delphi.
  • We have C++ builder demos and projects that we need to compile with SmartSetup.

So the current SmartSetup situation mimics the points above. We support compiling .cbprojs for projects (we have to, we need to compile C++ projects), but we haven't really tried compiling C++ packages. It might work, but my bets would be in that it doesn't. If you need to build C++ projects only, you will be fine, if you also need to build and install C++ packages, there might be some extra work needed in the smartsetup side to support that. Of course, if your packages can be stored in binary form, .binprojs will work with both C++ and Delphi packages.

About tms spec it was just a lack of time, and not even knowing if people will use that command or not. tms spec is trickier than it looks (you need to gather the info from the dprojs, and that info is in different places depending on if it is a package or an exe), and well, it is not a needed command, just a convenience one.

If this is a C++ project (as said, I don't think smartsetup will work with C++ packages), then the simplest solution is to create the file tmsbuild.yaml yourself instead of using tms spec.

You can find the full commented file here: smartsetup/tms/example-config/tmsbuild.yaml at main · tmssoftware/smartsetup · GitHub

Just download the file, delete the sections that don't apply to you (a lot of the sections aren't really needed for simple projects) and fill the other fields so they work with your app. If you want to look at an actual, working tmsbuild.yaml for a product, you can look here: smartsetup-registry/amelander.map2pdb/tmsbuild.yaml at main · tmssoftware/smartsetup-registry · GitHub
As you can see, it is much simpler than the full file, and yours will likely be similar, but the file I linked first has all the possible things you can do.

Hi Adrian,

thanks again for your detailed and very helpful comments. I actually don't want to create C++Builder based components, but only compile applications. With your help (and a bit looking through the sources), I was finally able to make SmartSetup starting a build based on a .cbproj.

However, by build failes with some unresolvable externals. I've tried to put together a minimal C++ Builder VCL project (only the File --> New C++ Builder VCL Project) and setup the project structure as explained in the recommended-folder-structure, but this failes with the same error.

I think I am pretty near - maybe only missing a simple thing - did you stumblef over this already?

Here is a screenshot from the logs:

I've uploaded the full sample here (including the build output): tms-cbuilder-ci-repo-root.zip

Would you be able to take a quick look?

Thanks

I am not sure what is going on here (not that expert in bcb), but let me explain what I've found:

The error is because it isn't linking the vcl library (you see all those missing external Vcl::... messages). It looked like something missing in the cpbroj.

So I tried compiling directly from the IDE, and it worked. But of course, compiling from command line didn't.

Next step was realizing that I had compiled from the IDE in debug mode, while smartsetup compiles in release... So I went back to the IDE, and compiled in release mode. When I went back to compile in smartsetup, it compiled cleanly.

Ok, so I diffed the files (the ones you sent, against the ones after compiling in release with the IDE), and what I saw is that originally, this cbproj missed the lines:

which were added when I compiled from the IDE in release mode. Note that it is for "Cfg_2" which is release in this case (It might switch depending in the cbproj, sometimes Cfg_1 is debug and sometimes Cfg_2 is debug, with release being Cfg_2/1 respectively).

So now I went to your original files, I added the line:

<LinkPackageImports>rtl.bpi;vcl.bpi</LinkPackageImports>

To Cfg_2 (it already was for Cfg1 in the original file), and it compiles cleanly:

(used d12, not 11, because I am on the road and only have d12/13 in this laptop. but it should be the same with d11)

So in short:

  • The file is missing vcl.bpi and rtl.bpi link packages
  • Why is it missing them? I don't know. But it looks like if you build in release from the IDE, it will add that missing line to the release config.

I am not sure how (and if) smartsetup could be improved to handle this case, but it looks like you can't really compile from the command line until you've compiled from the IDE, and those link files are added. And you need to compile in the IDE for the exact stuff you need (release, not debug, and both win32/64 if you want to create win32/64 apps). Each run will add the linkpackages to the correct config, not to all of them.

1 Like

Hi Adrian,

sorry, I missed this (release vs. debug). The IDE (alt least C++Builder) seems to only add the bpi files to the project, if you at least activate/build once with the given configuration (which I did not for the release configuration, sorry, my bad).

Actually I think it's more a bug in the IDE creating an "incomplete" project file and
there is no need to fix this from the tms end. For my use case (developing locally, then running the build on a CI server) this is perfectly good (and once we know what to look out for, we can easily handle it).

Thanks again for doing this fantastic work and helping me finding my bugs :grinning_face:

Thanks and best regards!