Xojo Build Automation/IDE Scripting

Ok, so I’m slowly getting the hang of build automation and I’m now experimenting with sending commands to the IDE (using the IDE communicator)

Since the IDE scripting language is a bit alien, probably the easiest way to do things would be to actually add a build script dynamically.

I want to use my “builder” app to:
Open a project in the IDE, or select it if it’s already open.
Change some constants and settings
Build the App for the appropriate platforms

I could do this by sending commands to the IDE, but making the correct project the “active” one (or checking which one is active) with if/thens and so on is tricky with IDE commands; I think it would be easier to just create a custom build script for the project dynamically, if that’s even possible…

I have 4-5 apps that make 3 different versions of my app. I just need to set a constant and everything else is done with an IDE communicator script. The start of the script is below:

dim MaxVersion as String = "0"
if MaxVersion = "" then MaxVersion = "0"

dim MajorVersion as string = "6"
dim MinorVersion as String = "0"
dim BugVersion as String = "0"
dim BetaVersion as String = "b1"

dim theCommand, theResult as string
dim userHome as String = DoShellCommand("echo $HOME")
userHome = Trim(ShellEncode(userHome))

dim basePath as string = userHome + "/Documents/Development/Mail\ Archiver/"

'delete old apps and dmg
theCommand = "osascript " + basePath + "code\ current/ide\ communicator/delete\ old\ builds.scpt"
theResult = DoShellCommand(theCommand)

'scheduler: : only for normal, pro and pro admin
if MaxVersion = "0" or MaxVersion = "1" or MaxVersion = "3" then
	openfile(basePath + "code\ current/max\ scheduler.xojo_xml_project")
	ConstantValue("App.kMaxVersion") = MaxVersion
	if ConstantValue("App.kMaxVersion") = "0" then
		PropertyValue("App.Application Identifier") = "com.mothsoftware.mailarchiverx-helper"
		PropertyValue("App.MacOSXAppName") = "Mail Archiver X "
	elseif ConstantValue("App.kMaxVersion") = "1" then
		PropertyValue("App.Application Identifier") = "com.mothsoftware.mailarchiverxpro-helper"
		PropertyValue("App.MacOSXAppName") = "Mail Archiver X Pro "
	elseif ConstantValue("App.kMaxVersion") = "3" then
		PropertyValue("App.Application Identifier") = "com.mothsoftware.mailarchiverxproadmin-helper"
		PropertyValue("App.MacOSXAppName") = "Mail Archiver X Pro Admin "
		print ConstantValue("App.kMaxVersion")
	end if
	makeVersion(MajorVersion, MinorVersion, BugVersion, BetaVersion)
	if BuildApp(16) = "" then
		DoCommand "SaveFile"
	end if
end if

The trick is having the base path. All projects are in this folder. It doesn’t matter if the other projects are open or not.

Thanks, @beatrixwillius .
So are you saying the “active” project will be the one you open using openfile? If it’s already open will it open it again?
What is the osascript command?

openfile should make that project the “active” or frontmost one with focus for the remainder of the script even if it was open already

Isn’t it DoCommand("OpenFile(""filename"")") or is OpenFile a command on it’s own?

Man, I wish there was a single pdf document that details ALL the Scripting stuff. It’s so hard to find things online, and of course what is there isn’t for my version… :frowning:

OpenFile should be fine all by itself

The vast majority of this hasnt had any huge changes

Thanks, @npalardy . Still would prefer one big PDF with links…

I doubt they’d produce such a thing
But, I’ve been wrong once before :stuck_out_tongue:

“I thought I was wrong once before, but it turns out I was mistaken.”

1 Like

Interesting that there’s a separate OpenFile() command, but SaveFile() has to be done using DoCommand() :blush:

IDE scripting was purpose built
It originated with early versions and needing some way to do some kind of automation of builds
So thats where the focus was - automating the few commands you would need to build the IDE
Its grown a bit since then
But to do a Build you would OPEN a project - maybe make some changes to constants etc, and Build
But you more than likely didnt want to save those changes
It’s also why things like accessing the project and its entire project model is not great - that wasnt required but has been added incrementally over the years

But the whole thing really needs a rewrite to do that kinds of things people ARE using it for

1 Like

i really tried to use IDE scripting and the IDE communicator to automate builds. and it worked when everything was perfect. but once anything was less than perfect, it would break down and break down hard.

saying that it needs a revamp is an understatement.

I was thinking that I HAVE to save the changes or they don’t take.
But… this doesn’t actually fix the issue. I have to run the script twice for some reason or the constants don’t update before the build.

osascript is macOS and allows to run AppleScripts with the shell.

@Meestor_X : The constants always update before the build. Please show your script.

@scott : what problems did you have? What is “less than perfect”?

Not if you’re using those constants as build values.
Eg. If Mac App Name is set to #Globals.kAppName and your build script (which is done before the build process) changes Globals.kAppName to a new value, it won’t register until you run it again.
Saving the project doesn’t fix it.


A work around might be to set the Mac App Name directly as in PropertyValue(“App.MacOSXAppName”) = "Tunnel-01" but I haven’t tried that yet.

I had a dedicated mac mini that ran nothing but OSX, Xojo and Gitlab Runner (the app that GitLab uses to run things on machines other than itself in the CI/CD process).

Gitlab Runner would ALWAYS pickup the task.

I was using the IDE Communicator (or Build Communicator or whatever the name is called). And that application would launch 100% of the time.

I had GitLab Runner launch Xojo (IDE) prior to doing anything with the IDE Communicator and it had a long pause between the Xojo launch and the IDE communicator launch, to make sure that Xojo was up and running.

Once IDE Communicator was open, GitLab Runner would tell it to run an IDE script (basically build auotmation). the script would tell Xojo to open the source code (full path), then build it (compile), then Xojo IDE to exit (no saving)

that script would complete on the IDE Communicator side 90% of the time. and on the Xojo IDE side about 75% of the time.

when it would fail. I could go back into Gitlab and tell it to rerun the pipeline, and it would work 85% of those times. the other 15% of the times, I would have to delete ALL Xojo caches (for the IDE, communicator, feedback, etc) and make sure the git directory (source code directory) and the artifacts (the builds/partial builds) are all clean. and generally at this point had to restart the mac. to get it working again.

now I had a monitor on the mac mini, and the GitLab runner was running on the logged in console/desktop (not a background service) so I could watch IDE Communicator and the IDE do what it was doing. or not doing.

I got to the point where I got tired of “tweaking” the CI/CD stuff and trying to automate the builds.

the IDE Communicator v2 is much better than v1. Gregg took a lot of feedback from the community and made major strides at making it better. just not there yet.

That sounds really bad. Never ever seen such behaviour with IDE communicator.

Did you do a Feedback report?

i might have. I dont use Xojo anymore except for patching old code so even if I did, it isnt handy.
Gregg and I swapped a lot of communications on this.

Now it works 100% perfect in their environment so they cant reproduce any issues anyone has.

Hey y’all. After all that fun of getting the IDECommunicator set up and working, I realized there was no reason to go to all that effort. Just have my “builder” app write a .xojo_script text file with all the custom settings and then add an “external script” build step before the compile in the program that need automating. Easy-peasy. Probably not telling you folks anything you don’t already know…

The communicator I guess would be good if you need to actually open the project & click “build”…
For me, I create the build script, then use it lots before I need to go back and make changes, so my new method works fine.

Still if you change the appname you have to build twice, but that’s no biggie.