Declare Refactoring

General
1

Can this be refactored? This is a typical declare in a routine. I have to account for Win, Mac, 32, 64, and the debug version needs to reference the library outside the bundle or area.

I’m unsure how @executablepath would work. I would hope that the Lib section could be set in constants, but how? Do I have to have 8 versions of each declare, like I’m doing below?

#if Target32Bit And TargetWindows Then #if DebugBuild Then Soft Declare Function CleanUpLibraryC Lib "@executable_path\\..\\..\\conversionengine" (Flags As Integer) As Integer #else Soft Declare Function CleanUpLibraryC Lib "conversionengine" (Flags As Integer) As Integer #endif #elseif Target64Bit And TargetWindows Then #if DebugBuild Then Soft Declare Function CleanUpLibraryC Lib "@executable_path\\..\\..\\conversionengine_x64" (Flags As Integer) As Integer #else Soft Declare Function CleanUpLibraryC Lib "conversionengine_x64" (Flags As Integer) As Integer #endif #elseif Target32Bit And TargetCocoa Then #if DebugBuild Or XCODE_DEBUG Then Soft Declare Function CleanUpLibraryC Lib "@executable_path/../../../conversionengine.dylib" (Flags As Integer) As Integer #else Soft Declare Function CleanUpLibraryC Lib "@executable_path/../Frameworks/conversionengine.dylib" (Flags As Integer) As Integer #endif #elseif Target64Bit And TargetCocoa Then #if DebugBuild Or XCODE_DEBUG Then Soft Declare Function CleanUpLibraryC Lib "@executable_path/../../../conversionengine_x64.dylib" (Flags As Integer) As Integer #else Soft Declare Function CleanUpLibraryC Lib "@executable_path/../Frameworks/conversionengine_x64.dylib" (Flags As Integer) As Integer #endif #endif

2

If the only thing that changes is the lib name then you can condense it a little by making the lib a constant:

[code]#if Target32Bit And TargetWindows Then
#if DebugBuild Then
Const LibPath = “@executable_path\…\…\conversionengine”
#else
Const LibPath = “conversionengine”
#endif
#elseif Target64Bit And TargetWindows Then
#if DebugBuild Then
Const LibPath = “@executable_path\…\…\conversionengine_x64”
#else
Const LibPath = “conversionengine_x64”
#endif
#elseif Target32Bit And TargetCocoa Then
#if DebugBuild Or XCODE_DEBUG Then
Const LibPath = “@executable_path/…/…/…/conversionengine.dylib”
#else
Const LibPath = “@executable_path/…/Frameworks/conversionengine.dylib”
#endif
#elseif Target64Bit And TargetCocoa Then
#if DebugBuild Or XCODE_DEBUG Then
Const LibPath = “@executable_path/…/…/…/conversionengine_x64.dylib”
#else
Const LibPath = “@executable_path/…/Frameworks/conversionengine_x64.dylib”
#endif
#endif

Soft Declare Function CleanUpLibraryC Lib LibPath (Flags As Integer) As Integer[/code]

3

@executable_path is a macOS thing and probably useless on Windows or Linux

4

Why not use a build script so that the Debug app library is in the same location? That would eliminate 1/2 of your variations

5

Because I alternate between debugging on REAL/Xojo and on XCode/Visual Studio. When debugging on XCode, it can’t place the new debug library it creates inside the app bundle, only outside it.

6

@Garth Hjelte
A Copy File Build Script would allow your Xojo debug run to grab the file from anywhere on your filesystem:
https://documentation.xojo.com/topics/build_automation/introduction.html

7

There are a few ways to do this:

  • First, XCode has build scripts too, so you could copy the item to the new location after building in XCode.
  • Or, use symbolic links to do what you want - you could have a Xojo post-build script which creates a symbolic link using the “ln -s” command.
8

Thanks for the info - I’ll go about this later when I have time. In the meantime I exercised my fingers and now my Declares for the my library for each function are MASSIVE =) but at least it’s consistent.

But it certainly does help answer the question, thank you.

9

Garth, there’s an additional case you need to worry about: Remote Debug.

So a full set of declares would be the combination of:
• OS (mac/windows)
• bits (32/64)
• build: regular, debug, or remote debug

So that’s 2x2x3 = 12 separate combinations.

(It’s actually more than that, since with remote debug you could be building on macOS and debugging on Windows, vs. building on macOS and remote debugging to macOS…)

Remote debug is a little difficult since build scripts can’t send files to the remote computer. Sometimes I handle this with a shared folder (in macOS you can share a folder as SMB and mount it from windows, or if using Virtual Machines just use the VM shared folder facility).

It gets complictated, but when done properly can be super useful.