This uses the same return values as BulidApp. I’ve also replicated the table here.
I’m not sure what this one is for yet.
It went live last December with the iOS release, but not with all the content that is there now.
I am adding content regularly. There are many links to it from the wiki, the IDE and the blog.
Very pleased to see this level of Wiki rolling out.
Are others going to be allowed to edit / submit?
It is not technically a wiki, so others cannot edit it.
Pages should have a “Was this information helpful?” section at the bottom that you can fill out to send feedback. And of course, Feedback itself can continue to be used for doc suggestions.
I’ve just thought about using a “Copy Files” build step to add an additional .dll for a Windows Build. Obviously, I need to copy a different .dll’s for 32Bit and 64Bit build.
Am I correct that there is still no way to do that?
Not an option, since I want to debug-run (32Bit for now, 64Bit hopefully soon) and having the appropriate/required .dll’s added, too.
I guess the only option is to use a Post Build Script, and copy the files via a Shell Command?
And in order to be able to DebugRun and build onWindows, and build on macOS, too - the ShellCommands obviously need to be depending on the Build-on-OS-Target…
So before I’m going to do that… is there really no built-in and simple way?
I see my name there all over 
But I still see no simple way of adding an additional 32Bit or 64Bit .dll, apart from doing it via Shell (with different shell-copy-Code for Builds on macOS vs. Window) in a PostScript Script. The upcoming new constants are convenient, but CurrentBuildTarget does that part of the trick already.
It’s coming in a future release. Note that Norman’s entries are from yesterday 
Im fully aware of that.
But it doesnt make it any easier to copy different files for 32/64Bit builds… or does it?
It’s supposed to as that’s what the request was for. 
I don’t think it will… at least not the way I understand it. <https://xojo.com/issue/51578> is just a couple of convenience constants for post build ide scripts, so that you can easily figure out if the current build is for 32bit or 64bit. you can do that already by checking the constant CurrentBuildTarget.
that “implemented” upcoming feature doesn’t allow to have a build step running depending on the architecture of the current build-in-progress.
So I guess (and that’s still my question) this still doesn’t allow us to use a simple “Copy File build step” to copy either a 32bit or 64bit resource… so once again: am I right that currently the only option is to use a post build script, and copy 32/64bit-specific additional files using an (os dependent) shell command (and checking CurrentBuildTarget to figure out if 32bit or 64bit)?
If so… <https://xojo.com/issue/41267> seems an overkill to me. Too much “noise” in the list of Targets.
But a quite simple feature such as this one would be a big help: <https://xojo.com/issue/51578> - Build Steps: allow to choose the architecture (32Bit, 64Bit, all) the build step applies to
This would finally allow us to use architecture specific build steps. And if someone needs to “build them all at once”, we can additionally use IDECommunicator.
Hmmm - I actually confused those two (I have them both in my favorites). 41267 is what I’m looking for so that I can have my Build Steps to copy the proper added files depending on the current build type.
As it sits now, I have 18 CopyFileStep files (3 for each platform) that have to be swapped from the main navigation level to the proper Build steps and then swapped back once the build completes.
Ah, that’s another idea or possible option…
So you would suggest to have 2 “Copy Files Steps” (for the above example with a Windows Build): 1 for the additional 32 Bit .dll, 1 for the additional 64 Bit .dll
But where do you place them, and how do you “swap” them? Do you do that manually, or can this be done auto-magically with yet another Build Step (script)?
Create the CopyFileStep files and name them Linux32bitCopy, Linux64bitCopy, etc.
Copy all of the ones that I’m not building in this run to the bottom of the Navigation list , but outside of the Build Automation section.
Run the Build
Copy all of the current steps to the Navigation list and copy in the alternates
Run the Build
Revert the copies so that I don’t muck up my version control.
You end up with something that looks like this:
A minor PITA, but it works for now.
I believe we need something like this:
[quote=377276:@Tim Jones]Create the CopyFileStep files and name them Linux32bitCopy, Linux64bitCopy, etc.
Copy all of the ones that I’m not building in this run to the bottom of the Navigation list , but outside of the Build Automation section.
Run the Build
Copy all of the current steps to the Navigation list and copy in the alternates
Run the Build
Revert the copies so that I don’t muck up my version control.
…
A minor PITA, but it works for now.[/quote]
Yup - not quite a nice way…
…I prefer an auto-magic way
That’s why I ended up writing a PostBuild Script. It copies the appropriate 32Bit/64Bit additional .dll’s to the just built app. Works for both DebugRun and Build/Release on Windows, and should work for Builds on macOS/Linux, too (I haven’t tested that yet).
Here’s the Post Build Script as “pseudo code” (which can be modified to copy other files and resources, and copy to another subfolder than the main executable):
[code] Dim sDLLs_SourceFolder As String
'Target
select case CurrentBuildTarget
case 3 'Windows 32Bit
if TargetWin32 then
sDLLs_SourceFolder = “%PROJECT_PATH%\build\Libraries\Windows\32Bit”
elseif (TargetMacOS or TargetLinux) then
sDLLs_SourceFolder = “$PROJECT_PATH/build/Libraries/Windows/32Bit/”
end if
case 19 'Windows 64Bit
if TargetWin32 then
sDLLs_SourceFolder = “%PROJECT_PATH%\build\Libraries\Windows\64Bit”
elseif (TargetMacOS or TargetLinux) then
sDLLs_SourceFolder = “$PROJECT_PATH/build/Libraries/Windows/64Bit/”
end if
end select
if (sDLLs_SourceFolder <> “”) then
'add the 32Bit or 64Bit .dll’s
Dim sAppBuildPath As String
if TargetWin32 then
sAppBuildPath = CurrentBuildLocation
elseif TargetMacOS or TargetLinux then
sAppBuildPath = ReplaceAll(CurrentBuildLocation, “”, “”) 'don’t escape Path
end if
if TargetWin32 then
call DoShellCommand("copy """ + sDLLs_SourceFolder + "MyAdditional.dll" + """ """ + sAppBuildPath + """ /y /v", 0)
else
call DoShellCommand("cp -f """ + sDLLs_SourceFolder + "MyAdditional.dll" + """ """ + sAppBuildPath + """", 0)
end if
end if
[/code]
That works for me now (with both REAL Studio 2011r3 and Xojo 2017; without having to fiddle with the Build Steps for every build) - until we finally get some nice and integrated way in the IDE for such a simple task.
That’s where I came FROM when I finally moved to Automation Build Steps - one IDE Script that handled all of that stuff that I ran from the File menu (when they should have been in the “Project” menu … ).
Here’s an oldie but a goodie:
Relocate Project-specific IDE scripts to the Projects Menu - <https://xojo.com/issue/44657>
@Tim Jones: Why did you move to those Copy steps? Granted, writing the IDE scripts is sort of painful. But I still manage to screw up those Copy steps now and then. Then they loose their files and there is no warning when you build.
I have never had a CopyFiles step “lose” it’s files. Do you regularly move projects and files around?