Post a Reply
6133 views

We need separate Build Automation steps for 64bit builds

  1. ‹ Older
  2. 2 years ago

    Tim J

    12 Mar 2018 Pre-Release Testers Dehydrating in AZ

    @Beatrix W @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.

    Because if you have both the 32bit and 64bit CopyFileStep files in the Build Automation, the Build pass executes both of them.

  3. Jürg O

    13 Mar 2018 Pre-Release Testers, Xojo Pro Answer

    @Tim J Because if you have both the 32bit and 64bit CopyFileStep files in the Build Automation, the Build pass executes both of them.

    It seems there is an easier way than manually moving the 32bit/64bit "Copy Files steps".

    An example for Windows - in a situation where you want to add 32Bit or 64Bit .dll's:
    Build Settings -> Windows -> Build: PostBuildSteps

    1. CopyZlib_Setup (Script, Source see below; needs to be above the next two steps)
    2. CopyZlib_32Bit (CopyFile Step, which adds the 32Bit .dll)
    3. CopyZlib_64Bit (CopyFile Step, which adds the 64Bit .dll)

    BuildScript "CopyZlib_Setup":

      'Reset
  PropertyValue("CopyZlib_32Bit.Applies to") = "3" 'None
  PropertyValue("CopyZlib_64Bit.Applies to") = "3" 'None
  
 'Enable depending on CurrentBuildTarget
  select case CurrentBuildTarget
  case 3 'Windows 32Bit
    PropertyValue("CopyZlib_32Bit.Applies to") = "0" 'Both Debug and Release
  case 19 'Windows 64Bit
    PropertyValue("CopyZlib_64Bit.Applies to") = "0" 'Both Debug and Release
  end select[/code]


    This will dis/enable the CopyFile Steps depending on the CurrentBuildTarget.
    So you can leave both 32Bit/64Bit Copy File Steps in the PostBuild section - and they will get activated depending on the current Build Settings.

    Note: This won't work for 2011r3, as the "Applies to: None" has been introduced somewhen later... It's there in 2016r3.

  4. 2 months ago

    Tim J

    Sep 16 Pre-Release Testers Dehydrating in AZ
    Edited 2 months ago

    @Jürg O It seems there is an easier way than manually moving the 32bit/64bit "Copy Files steps".

    This will dis/enable the CopyFile Steps depending on the CurrentBuildTarget.
    So you can leave both 32Bit/64Bit Copy File Steps in the PostBuild section - and they will get activated depending on the current Build Settings.

    Note: This won't work for 2011r3, as the "Applies to: None" has been introduced somewhen later... It's there in 2016r3.

    Jürg - I don't know why I never received your response above, but thank you for ferreting out this solution. I've implemented it in one of my projects that is compiled for both Windows and all three Linux platforms and it has saved my hair (from being pulled out :) ).

    Here's my version for all 6 platforms:

    ' Original concept by Jürg Otter
' Reset
PropertyValue("CopyLinuxSharedLibs32Bit.Applies to") = "3" 'None
PropertyValue("CopyLinuxSharedLibs64Bit.Applies to") = "3" 'None
PropertyValue("CopyLinuxSharedLibsarm32.Applies to") = "3" 'None
PropertyValue("CopyWindowsSharedLibs64Bit.Applies to") = "3" 'None
PropertyValue("CopyWindowsSharedLibs32Bit.Applies to") = "3" 'None
PropertyValue("CopymacOSSharedLibs64Bit.Applies to") = "3" 'None
PropertyValue("CopyLinuxHelpers32Bit.Applies to") = "3" 'None
PropertyValue("CopyLinuxHelpers64Bit.Applies to") = "3" 'None
PropertyValue("CopyLinuxHelpersARM32.Applies to") = "3" 'None
PropertyValue("CopyWindowsHelpers64Bit.Applies to") = "3" 'None
PropertyValue("CopyWindowsHelpers32Bit.Applies to") = "3" 'None
PropertyValue("CopymacOSHelpers64Bit.Applies to") = "3" 'None

' Enable depending on CurrentBuildTarget
select case CurrentBuildTarget
case 16 'macOS 64bit
  PropertyValue("CopymacOSSharedLibs64Bit.Applies to") = "0"
  PropertyValue("CopyWindowsHelpers64Bit.Applies to") = "0"
case 4 'Linux 32Bit
  PropertyValue("CopyLinuxSharedLibs32Bit.Applies to") = "0"
  PropertyValue("CopyLinuxHelpers32Bit.Applies to") = "0"
case 17 'Linux 64bit
  PropertyValue("CopyLinuxSharedLibs64Bit.Applies to") = "0"
  PropertyValue("CopyLinuxHelpers64Bit.Applies to") = "0"
case 18 'Linux ARM32
  PropertyValue("CopyLinuxSharedLibsarm32.Applies to") = "0"
  PropertyValue("CopyLinuxHelpersARM32.Applies to") = "0"
case 19 'Windows 64Bit
  PropertyValue("CopyWindowsSharedLibs64Bit.Applies to") = "0"
  PropertyValue("CopyWindowsHelpers64Bit.Applies to") = "0"
case 3 'Windows 32Bit
  PropertyValue("CopyWindowsSharedLibs64Bit.Applies to") = "0"
  PropertyValue("CopyWindowsHelpers64Bit.Applies to") = "0"
end select

  5. Emile S

    Sep 16 Europe (France, Strasbourg)

    Crazy reminder:

    now that 64 bits is mandatory, isn't it a good idea to clear the 32 bits compile * (at one time in the future, soon) ?

    * This year’s macOS version stop accepting 32 Bits applications, so… conclude by yourself !

  6. Norman P

    Sep 16 Pre-Release Testers, Xojo Pro Outside

    Windows 10 is still available in 32 or 64 bit
    RPi's can run either

    Most new distros of linux are 64 bit as are macOS and iOS

  7. Tim J

    Sep 16 Pre-Release Testers Dehydrating in AZ
    Edited 2 months ago

    @Emile S isn't it a good idea to clear the 32 bits compile

    Note in my list that I'm only compiling for active platforms - including 64bit macOS. WE also have customers who are still using 32bit Linux and Windows systems.

  8. Jürg O

    Sep 16 Pre-Release Testers, Xojo Pro
    Edited 2 months ago

    @Tim J Jürg - I don't know why I never received your response above, but thank you for ferreting out this solution.

    You're welcome ;)

    I'm still waiting for Xojo to improve the Build Steps like this:

    • at a minimum: Feedback Case #51587 Build Steps: allow to choose the architecture (32Bit, 64Bit, all) the build step applies to
    • at best: Feedback Case #51610 Build Steps: allow a scriptable condition to check if a build step should be executed

    That would be so much better and allow us fine-grained control of build steps... ;)

or Sign Up to reply!