Some invalid information inside packages

[agallero]

• The package https://github.com/DelphiWorlds/Kastri/blob/master/Packages/KastriFMX.dpk has hadcoded Z:\ inside. It should be ..\
• Same happens for https://github.com/DelphiWorlds/Kastri/blob/master/Packages/KastriFMX.dproj
• https://github.com/DelphiWorlds/Kastri/blob/master/Packages/KastriBuild.dpk misses a "in" the contains section. It should be:

contains
  DW.Precompile in '..\Core\DW.Precompile.pas';

[DelphiWorlds]

The package https://github.com/DelphiWorlds/Kastri/blob/master/Packages/KastriFMX.dpk has hadcoded Z:\ inside. It should be ..
Same happens for https://github.com/DelphiWorlds/Kastri/blob/master/Packages/KastriFMX.dproj

Fixed.

https://github.com/DelphiWorlds/Kastri/blob/master/Packages/KastriBuild.dpk misses a "in" the contains section. It should be: contains DW.Precompile in '..\Core\DW.Precompile.pas';

Does it not compile for you? If it does compile, then it's not an issue

[agallero]

Does it not compile for you? If it does compile, then it's not an issue

Indeed it doesn't compile for me (that's why I reported it 🙂 ). But mine is not a normal case, in general I think it should compile, so I leave the decision if to change it or not to you.

I started commenting more on why I found this in the original report, but then it just looked that I was doing the report longer for no reason, so I delete it. But if you want the longer story, it goes like this:

In 2023 we released a new installer for tms products which had been in development for a while (https://www.tmssoftware.com/site/blog.asp?post=1146). After that, we got many requests from people to support open source products, so we open source the installer itself (https://www.tmssoftware.com/site/blog.asp?post=1360) and we plan to launch a v2.0 focused in installing open source products too in the coming weeks.

In the meantime, I am trying the compiler with a lot of existing open source libraries, to test how well it works, and also to create a "repository" of working repos so you can just type for example "tms install library" and it will fetch if from github and install it. The current repo with products that can already be installed is here: https://github.com/tmssoftware/smartsetup-registry/tree/main

So I was looking to add Kastri to that list. Creating the yaml file is a 10-minute work (and I've already ported much more projects than the ones uploaded to the registry), but sometimes there are errors. In the case of Kagi, I first got the "z:" error, and when I fixed there, it complained about the "contains" line not having a "in" part. This is because we parse the dpk and modify some parts to compile.

Once I fixed those 3 things, it was working:

But I am not 100% sure this is a good fit for smartsetup, because I think the idea is to work just by adding the sources to the library path, and we work with packages. I believe that just by installing the packages (and adding paths to the dcus), a lot of units just won't be available. So it is probably better to leave it to install by the traditional method.

Well, that was the full story, I hope it wasn't too long. As said, it is not really an issue for me unless I want to install with smartsetup, so the decision if to fix it or not is 100% yours

[DelphiWorlds]

I've fixed it now, so that it's compatible with smartsetup, however since Delphi considered the source valid code, smartsetup might need to be fixed sometime in the future so that it doesn't "break" on other projects that do the same thing :-)

[agallero]

Thanks! The main issue with dpks is that they are quite "free-form", so making a real parser for them might imply doing a pascal parser. So well, it is a balance, we try to support "standard" dpks. Sometimes we need to fix something, sometimes it needs to be fixed in the dpks.

SmartSetup was at the beginning really picky about the way it needed the dprojs/dpks to be, we are relatxing that a lot now. And that's also one of the reasons I am looking at actual libraries in github, to see what things we can expect and what not. Kastri was the first project I saw that didn't had the "in" in the dpks, and it was a single file, so it looked simpler to just fix that. But indeed, it might be fixed on our side in the future if the need arises.

Right now, I could add support for a lot of projects I tried in 15 minutes or so each, but the most common 2 issues I see that prevented me in the others are:

1. Missing dprojs/dpks at all. Many libs just have sources and no projects.
2. Dprojs missing {$LIBSUFFIX} . SmartSetup can install in multiple delphi versions at the same time, so we require a libsuffix. Doesn't need to be the standard one, but there must be one.

For both points, our idea is to provide a way to autogenerate dprojs and dpks, which would fix both problems. But that's for the future.

Now, back to the original topic. Sorry, in my original report I forgot another change I had made to compile:

• KastriBuild.dpk is missing a {$LIBSUFFIX AUTO} line

If I add this, I get it working as before. But now I am getting some errors in some platforms (originally I had tried only win32 and win64), which I can also reproduce directly from the IDE:

The android errors in D11 are:

R:\castle\Products\Kastri\API\DW.Androidapi.JNI.AndroidX.Camera.pas(841): error E2003: Undeclared identifier: 'JRational' [R:\castle\Temp\p\delphiworlds.kastri_d11_android32_Release\KastriBuild.dproj] R:\castle\Products\Kastri\API\DW.Androidapi.JNI.AndroidX.Camera.pas(2020): error E2005: 'JRational' is not a type identifier [R:\castle\Temp\p\delphiworlds.kastri_d11_android32_Release\KastriBuild.dproj] R:\castle\Products\Kastri\API\DW.Androidapi.JNI.AndroidX.Camera.pas(2268): error E2005: 'JRational' is not a type identifier [R:\castle\Temp\p\delphiworlds.kastri_d11_android32_Release\KastriBuild.dproj] R:\castle\Products\Kastri\API\DW.Androidapi.JNI.AndroidX.Camera.pas(2275): error E2005: 'JRational' is not a type identifier [R:\castle\Temp\p\delphiworlds.kastri_d11_android32_Release\KastriBuild.dproj] R:\castle\Products\Kastri\API\DW.Androidapi.JNI.AndroidX.Camera.pas(2285): error E2005: 'JRational' is not a type identifier [R:\castle\Temp\p\delphiworlds.kastri_d11_android32_Release\KastriBuild.dproj]

I am not sure if this could be caused by some misconfig on my side? I can see the same if I try to compile it from the IDE directly, no smartsetup at all.

The linux error is (both D11 and D12):

R:\castle\Products\Kastri\Features\Connectivity\DW.Connectivity.pas(92): error E2003: Undeclared identifier: 'GetLocalAddresses'

But I see that castribuild doesn't support linux, so maybe that's the reason?

Ok, to compile, I just removed those platforms from compiling. I've added the Kastri definition to our repository here: https://github.com/tmssoftware/smartsetup-registry/blob/main/delphiworlds.kastri/tmsbuild.yaml

(it will work if you can add the {$LIBSUFFIX AUTO})

If you want to test it, the steps would be:

1. You need a build from source Smartsetup (we plan to release 2.0 soon, but not yet). You need to clone https://github.com/tmssoftware/smartsetup.git and switch to the branch "git-registry"
2. Once it is built open a command line, make some folder (say z:\kastrismartsetup), cd z:\kastrismartsetup
3. tms server-enable community
4. tms install *kastri*

That should be it. Some other stuff that might be helpful: tms config -> Will open a config file for extra configuration tms log-view -> will open the browser with a list of errors during build tms build (and tms build -full) will rebuild the package after you make some changes. "-full" will force a rebuild even of what didn't change.

You can play with the file tmsbuild.yaml at the root. To make it work right now, I had to define a fmxD11 and fmxD12 frameworks, but ideally it should be a single one:

supported frameworks:
  fmx:
    ide since: delphi12
    platforms:
      - win32intel
      - win64intel
      - macos64intel
      - macos64arm
      - iosdevice64
      - iossimulator64arm
      - android32
      - android64
      #- linux64

    c++ builder support: true

packages:
  - KastriFMX: [runtime, fmx]
  - KastriAdMob: [runtime, fmx]
  - KastriBuild: [runtime, fmx]

The good thing if you configure it, is that you get a simple way to check all platforms and all supported delphi versions are compiling before a release with a single command (tms build)

[DelphiWorlds]

But I see that castribuild doesn't support linux, so maybe that's the reason?

It should, actually. I originally started supporting Linux, but the project was last saved using an IDE that does not have the Linux feature installed, and unfortunately the IDE stupidly "disables" (or deletes) any platforms that you don't have installed. My interest in Linux has waned somewhat because there's yet to be ARM support for it.

(it will work if you can add the {$LIBSUFFIX AUTO})

Thanks for the tip.

On the point of Delphi 11 - is it Delphi 11.3? It seems your tests should not just be for the major releases, since for example new APIs can be added to point release - What does not compile in 11.0 may well compile in 11.3.

With Kastri, I support only from the last point release of the last major version onwards, i.e. 11.3, 12.0, 12.1, 12.2 and 12.3. When 13 comes out, any changes I make that do not compile (or work) in 11.3 will not be fixed.

Supporting older versions is way too time consuming, and since Kastri is 99% focused on cross-platform, developers should be keeping up to date anyway.

[agallero]

My interest in Linux has waned somewhat because there's yet to be ARM support for it.

I have the same feelings. Without ARM, it is not that useful.

On the point of Delphi 11 - is it Delphi 11.3?

It is indeed. We have a similar policy with our components, it is just impossible to support all previous versions of a dot release. Or at least I believe it is the latest, but I am not 100% sure. This is my version number:

Is it the same as yours? Could this be added in some patch/hotfix I didn't apply here?

The error I see:

Also searching through the sources of D11, I can't find jrational:

While they are in D12:

[DelphiWorlds]

I've pushed a change to DW.Androidapi.JNI.AndroidX.Camera.pas that should fix it