I've requested a new IDE Script Property for the Built App Path

Hi Folks,

I’m reworking some old post-build IDE Scripts for handling things like codesigning and packaging and it’s getting complex having to deal with all of the new locations that we get with the various platform types. To assist in simplifying this, I’ve submitted feature request <https://xojo.com/issue/44131> to add a AppBuildShellPath property that actually points to the built app folder.

Please adopt and comment if this is something that would be useful to you.

The result of the IDE script Build command should be useful

I’m not running a full script, just an “after” script in the build automation steps -

An example of how you’d use this would be useful
I suppose that would be for the codesign step you have in there ?

The codesign and package steps.

I’m currently getting the ProjectShellPath and then adding the sub folders to the app’s folder manually - such as:

  Dim theRes As String
  
  Function getCurrentBuildLocation() as String
    dim s, sa(), projname, pathdelim as string
    
    //Set the delimiter for the path based on the platform
    if TargetWin32 then
      pathdelim = "\"
    else
      pathdelim = "/"
    end if
    
    //Get the project path
    s = ProjectShellPath
    
    //Split into items
    sa = split(s,pathdelim)
    
    //Retrieve the project name so we can use it later
    projname = sa(UBound(sa))
    
    //Remove the project name
    sa.remove(UBound(sa))
    
    //Add the builds folder
    sa.append "Builds\\ \\-\\ " + projname
    
    //Join the array to create the new path
    s = join(sa,pathdelim)
    
    return s
  End Function
  
  theRes = DoShellCommand("codesign --deep -s ""Developer ID Application: TOLIS Group, Inc."" " + getCurrentBuildLocation + "/Mac\\ OS\\ X\\ \\(Cocoa\\ Intel\\)/BRU\\ PE.app", 40000)
  If theRes <> "" Then
    Print "Issue with codesign" + EndOfLine + theRes
  Else
    theRes = DoShellCommand("codesign -vv " +  getCurrentBuildLocation + "/Mac\\ OS\\ X\\ \\(Cocoa\\ Intel\\)/BRU\\ PE.app", 40000)
    Print "codesign successful" + EndOfLine + EndOfLine + theRes
  End If

I see … will have to peek & see whats possible since this does still use IDE scripting commands and so you could call them out of order at any time

that make things a bit wonky

would seem a native path would be useful

In my situation, they would only EVER be called AFTER the Build step, so the resulting path would always be available.

these are still general IDE script commands regardless of whether you use them in a build step or a hand written IDE script

There are no “build step only commands”

Since the build path will be known since you have to create the path to do the build, it would be known before or after the build and this should be a non-issue.

not really but then what do I know :slight_smile:

Why would it be bogus? The path would be correct (since that’s where the linker will put it), it just night not exist yet.

Because the IDE actually DOESN’T KNOW where it will go beyond the name of the folder to build it into

Okay - so how does the IDE tell the compiler / linker where to do their thing?

Never mind - but THAT folder is all we need.

The IDE says “build the mac os x cocoa 32 bit version HERE” and gives it a “base name”
The compiler tells the IDE, after building , I built THIS here - it literally returns a folder item to the IDE
So the IDE cant 100% accurately calculate the name at any point before the build happens because the compiler CAN and MAY change the absolute path (like by stuffing it into a directory in the build folder during a debug run etc)

The BEST you could get is where the IDE thinks it would be built (the folder)

And of course not using build folders makes things different
So while this might not affect YOU what is possible has to take all these things into account to try & do the right thing

Okay, can we at least get a property that will provide the proposed build folder so we don’t have to play that game of manually constructing the path as above?

You already know the answer is “this may or may not appear in some future version”