Does FinalBuilder 8.6.0.3631 support Delphi’s 13.1’s WinARM64EC target? If I look in the Build Delphi action’s Project tab, the Platform combo only shows Win32, Win64,Win64x, OSX64, OSX64ARM, and Linux64.
We haven’t released an update with WinARM64EC yet, still nailing down the command line compiler options around debug info/remote debugger symbols - we should have an update either today or tommorrow.
This build has the WinARM64EC platform enabled for D13
https://downloads.finalbuilder.com/downloads/finalbuilder/860/FB860_3645.exe
I’m still chasing up some compiler options clarity with embarcadero so there may be further minor changes before we release an official update.
Thanks Vincent, I appreciate the quick turnaround.
Edit: Nevermind the below, I saw that Action.Platform was a TPlatform in the autocomplete, and doing Action.Platform = TPlatform. showed the correct values.
~~
Our current FB project compiles for both Win32 and Win64 by having a BeforeAction() callback that does:
if CPUArch = "x86" then
Action.Platform = 0
else
Action.Platform = 1
I tested setting the platform to WinARM64EC in the UI and printing the value showed 3, which means it’s just the index into the combobox and therefore may get out of sync if/when other platforms are added/removed. Are there named constants or a different way that I should be handling this? If there are constants, are they documented anywhere? I haven’t been able to find explicit coverage of what each of the actions exposes to scripting, so I’ve just been relying on the autocomplete dropdown so far.
~~
I did run into two minor issues when updating, related to the new SFTP library:
- The “SFTP Upload” action previously allowed a blank destination path, in which case it uploaded to the login home directory with the source file’s name. That no longer works.
- The old library allowed using PuTTY .ppk files for the private key and the new one reported them as invalid.
Both issues were easy to resolve, so no need for another build, but I figured I should mention them.
The TPlatform enum is registered with the the script engine (it registers each value as a constant in js), so you can do
if CPUArch = "x86" then
Action.Platform = Win64
else
Action.Platform = WinARM64EC
It’s not documented anywhere - our documentation on scripting is very lacking.
I’ll look into the SFTP issue - that might be an oversight on our part or it might be a limitation of the new library (devart securebridge).
Looking into the SFTP issues - securebridge raises an exception if the dest is empty - so we guarded against that - I will change it so that if it is empty we get the users home directory and use that - so the old behavior will be restored.
Securebridge does support putty private keys, so not sure what the issue was there. What version of ppk was it (v2 or v3)? Was it password protected? Key type (RSA/DSA/ECDSA/EdDSA/SSH-1RSA)?
You can chalk the SFTP issue up to pseudo user error: The key was a 4096-bit ssh-rsa in PuTTY v2 format. It doesn’t have encryption, but some previous version of FB wouldn’t accept a blank password, so the action has a dummy value set for it that the old SFTP library apparently didn’t use. With the invalid password, the new library gives a “Key is broken” error. Removing the dummy value lets the connection go through. The OpenSSH version of the file also isn’t encrypted, but leaving the dummy password in does work there.
The build you provided has a broken “SFTP List Files” action. I have a test project with one variable (Listing) and with three actions:
SFTP Connect: SFTPHost
SFTP List Files: SFTPHost => Listing
Log Variable Values: Listing
The properties for SFTP List Files are:
<connection defined in SFTP Connect>
[ ] Reconnect if not connected
Remote path: /home/build/BcPackages
Mask: bcompare*
[ ] Case sensitive
[ ] Include Directories
[x] Include Files
[ ] Recursive
[ ] Long filenames
Log listing to variable: Listing
The Log Variable Values at the end shows no results.
From the Windows command line if I do
C:\> sftp user@sftphost
sftp> cd /home/build/BcPackages
sftp> ls
The results are
bcompare.x86_64.rpm
bcompare.x86_64.tar.gz
bcompare_amd64.deb
Using a trailing / in the SFTP List Files Remote Path doesn’t help.
Looks like your post got cut off?
I just tested the SFTP List files action with OpenSSH 10 and Bivise (windows) and it worked as exepected.
Sorry, yeah, hit Ctrl+Enter instead of Shift+Enter. Fixed now. The remote host is running RedHat Enterprise Linux 9. Our sysadmin won’t be on for a while, so I’m not sure of the specific SFTP server used, but it’s likely whatever the default one is.
Ok I can reproduce - looking into it.
A minor secondary issue: I’ve just been installing new versions over the top of our existing ones rather than uninstalling before upgrading and I ended up with two sets of “SFTP” actions with different icons. One set was in the “Internet” category" with white icons and the second set in the “SFTP” category with dark mode friendly ones. Trying to create the project above with both sets of commands gave errors about invalid property names when trying to save. Uninstalling and reinstalling has me back to just a single set (the “SFTP” ones with dark mode icons), but you might want to tweak the installer to either suggest an uninstall or clean up whatever .bpl/.dll was sitting around on an upgrade.
Yeah there was a bug in the installer (it was supposed to delete the old sftp files) - I was actually planning a release today (it’s 7pm here) but didn’t get to it.
We’ll put a release out next week but hopefully I can find a solution for the list files issues and provide a build shortly.
This build has the fix
https://downloads.finalbuilder.com/downloads/finalbuilder/860/FB860_3648.exe
Thanks for the amazingly fast turnaround!
It does work differently than the old actions in that it used to only return the filename (or relative path?) rather than fully qualified ones. I can work around that if necessary, though if I need to, please consider making the “Path Manipulation” action optionally work with / instead of \. I can use other methods easily enough, but that was the first thing I tried reaching for.
In any case, thanks again, and I hope you have a good weekend. 