First of all, thank you for the enormous amount of work that went into B4i and especially into the native library / XCFramework build process. It is a very valuable feature, and I am posting this only as a small contribution that might help improve one edge case.
The general issue seems to be related to spaces in native custom library names.
When a B4i project is compiled as a native library, the value of #LibraryName is not only used as a logical B4X library name. It is also used while generating the Xcode project, including file references, framework references, target names, product names and the bundle identifier.
This means that a library name containing spaces can become part of generated Xcode project fields such as:
Some of these fields require proper quoting when spaces are used. Other fields, especially the bundle identifier, cannot contain spaces at all and need a sanitized value. Apple allows only alphanumeric characters, hyphens and periods in bundle identifiers.
So the expected generated output would need to be closer to:
The XUI Views.b4xlib case below is only used as a concrete example because it is a well-known B4X library and makes the issue easy to reproduce and discuss. The same problem should affect any native B4i custom library whose #LibraryName contains a space.
In this example, the project uses:
B4i successfully parses and transpiles the code, creates the XML file and creates the Xcode project. The failure happens later when xcodebuild tries to read the generated project:
Looking into the generated project.pbxproj, it seems that the library name is written into several Xcode project fields without quoting / escaping the space.
For example, the generated project contains:
The corresponding generated values would need to be quoted or sanitized depending on the field:
The bundle identifier is a special case. Spaces are not valid there, and according to Apple's rules only alphanumeric characters, hyphens and periods are allowed. So this field probably needs a sanitized value instead of just quoting.
Here are the exact examples from the generated project.pbxproj:
Expected / safer output:
The target name is also written unquoted:
Expected / safer output:
And the generated bundle identifier contains the space:
Expected / safer output:
My conclusion is that native B4i library builds currently have a general issue with spaces in #LibraryName, because this value is used as part of generated Xcode project paths, names, framework/header references and the bundle identifier.
A straightforward solution would seem to be quoting the library name directly in the provider project:
However, this is not accepted by the B4i IDE. The IDE reports this as invalid code because of illegal characters in the directive. So the issue cannot currently be solved on the project side by explicitly quoting the #LibraryName value.
I have a lot of respect for the amount of work behind this toolchain. I wanted to report the issue with concrete generated output, in case it helps identify where quoting or sanitizing may be needed.
The general issue seems to be related to spaces in native custom library names.
When a B4i project is compiled as a native library, the value of #LibraryName is not only used as a logical B4X library name. It is also used while generating the Xcode project, including file references, framework references, target names, product names and the bundle identifier.
This means that a library name containing spaces can become part of generated Xcode project fields such as:
B4X:
path = Some Library.h;
path = Some Library.framework;
name = Some Library;
productName = Some Library;
PRODUCT_BUNDLE_IDENTIFIER = de.example.Some Library;Some of these fields require proper quoting when spaces are used. Other fields, especially the bundle identifier, cannot contain spaces at all and need a sanitized value. Apple allows only alphanumeric characters, hyphens and periods in bundle identifiers.
So the expected generated output would need to be closer to:
B4X:
path = "Some Library.h";
path = "Some Library.framework";
name = "Some Library";
productName = "Some Library";
PRODUCT_BUNDLE_IDENTIFIER = de.example.Some-Library;The XUI Views.b4xlib case below is only used as a concrete example because it is a well-known B4X library and makes the issue easy to reproduce and discuss. The same problem should affect any native B4i custom library whose #LibraryName contains a space.
In this example, the project uses:
B4X:
#LibraryName: XUI ViewsB4i successfully parses and transpiles the code, creates the XML file and creates the Xcode project. The failure happens later when xcodebuild tries to read the generated project:
B4X:
xcodebuild: error: Unable to read project 'B4iProject.xcodeproj'.
Reason: The project ‘B4iProject’ is damaged and cannot be opened due to a parse error.Looking into the generated project.pbxproj, it seems that the library name is written into several Xcode project fields without quoting / escaping the space.
For example, the generated project contains:
B4X:
path = XUI Views.h;
path = XUI Views.framework;
name = XUI Views.h; path = XUI Views.h;
name = XUI Views;
productName = XUI Views;
PRODUCT_BUNDLE_IDENTIFIER = de.example.xuiviews.XUI Views;The corresponding generated values would need to be quoted or sanitized depending on the field:
B4X:
path = "XUI Views.h";
path = "XUI Views.framework";
name = "XUI Views.h"; path = "XUI Views.h";
name = "XUI Views";
productName = "XUI Views";
PRODUCT_BUNDLE_IDENTIFIER = de.example.xuiviews.XUI-Views;The bundle identifier is a special case. Spaces are not valid there, and according to Apple's rules only alphanumeric characters, hyphens and periods are allowed. So this field probably needs a sanitized value instead of just quoting.
Here are the exact examples from the generated project.pbxproj:
B4X:
17698BB92ADFA1162F0EB821 /* XUI Views.h */ = {
isa = PBXFileReference;
fileEncoding = 4;
lastKnownFileType = sourcecode.c.h;
path = XUI Views.h;
sourceTree = "<group>";
};Expected / safer output:
B4X:
17698BB92ADFA1162F0EB821 /* XUI Views.h */ = {
isa = PBXFileReference;
fileEncoding = 4;
lastKnownFileType = sourcecode.c.h;
path = "XUI Views.h";
sourceTree = "<group>";
};The target name is also written unquoted:
B4X:
name = XUI Views;
productName = XUI Views;Expected / safer output:
B4X:
name = "XUI Views";
productName = "XUI Views";And the generated bundle identifier contains the space:
B4X:
PRODUCT_BUNDLE_IDENTIFIER = de.example.xuiviews.XUI Views;Expected / safer output:
B4X:
PRODUCT_BUNDLE_IDENTIFIER = de.example.xuiviews.XUI-Views;My conclusion is that native B4i library builds currently have a general issue with spaces in #LibraryName, because this value is used as part of generated Xcode project paths, names, framework/header references and the bundle identifier.
A straightforward solution would seem to be quoting the library name directly in the provider project:
B4X:
#LibraryName: "XUI Views"However, this is not accepted by the B4i IDE. The IDE reports this as invalid code because of illegal characters in the directive. So the issue cannot currently be solved on the project side by explicitly quoting the #LibraryName value.
I have a lot of respect for the amount of work behind this toolchain. I wanted to report the issue with concrete generated output, in case it helps identify where quoting or sanitizing may be needed.
