includeURLs are the paths to the current working directory /Users/gtavares/Desktop/Browser/gtktest and the current installed version of the Objective-J framework /Users/gtavares/Developer/cappuccino/dist/objective-j/Frameworks. What is missing is the path to the current installed Cappuccino framework /Users/gtavares/Developer/cappuccino/dist/cappuccino/Frameworks. I think this is a bug in the @objj/runtime node module. I will look into why this is happening.Also, keep in mind that the path to the current Build directory is usually not included in the
includeURLs but could be added manually with the environment variable OBJJ_INCLUDE_PATHS
Property List error: Unexpected character N at line 1 / JSON error: JSON text did not start with array or object and option to allow fragments not set. around line 1, column 0.
imagesize needs to be replaced in the node version — it is used by nib2cib if a xib contains images.
imagesize required if a xib contains an image :-) For the immediate need it can be loaded programmatically, and will be in the final version. I’m wondering what else isn’t quite there, though?
imagesize - is that one of the legacy Java-native tools?
flatten and press are optional parts of the toolchain but nib2cib isn’t — it must run using node for the full set of usage cases.
Highlights, fwiw, that we don’t have anything like the testing needed for the toolchain itself. It’s not suprising parts of it are brittle. When teaching software architecture courses in the 90s , it’s what we called ‘an opportunity for improvement’ ;-)
press and flatten is not yet supported in the Node version but nib2cib is. imagesize and fontinfo is native Mac OS tools and is only needed when running nib2cib as you say. The need to convert imagesize and fontinfo to something else is not high on my list.
gtktestwritten in Objective-J. I have tested myself with a simple Objective-J tool with a shebang like this #!/usr/bin/env objj and it does now work. The update is in the @objj/runtime
Which returns me to my original thinking - the toolchain is very brittle, but any work on it is seemingly best directed at filling in the current gaps when running under node.
This is a bit problematic just yet - both inline and external documentation of toolchain components are Spartan in the extreme, with domain knowledge seemingly gone with the original authors. And, there is an apparent unwillingness to form a consensus on just what should be supported, what functionality is critical, and on what platforms.
fwiw, this comes to mind: fontinfo and imagesize are currently native macOS utilities. Their normal use is by nib2cib — this implies that tool should only ever be usable on the macOS platform. Nevertheless, the xib format is XML and thus ripe for auto generation and maniplulation by external tools - on any platform. Should fontinfo and imagesize be left as-is, or should platform-agnostic versions be substituted, leaving open the option for eliminating ibtool and plutil dependance and making the toolchain cross-platform (conceptutually, at least).
As it turns out, imagesize has other problems. It doesn’t escape spaces in pathnames, and thus fails in the same way the autotools suite does. And, on my own Monterey installation, it is failing to build and install when Cappuccino source is bootstrapped.
One of the (perhaps minor) advantages of moving to node is escaping the prison of autotools requiring pathnames without spaces in.
All other effort should be directed towards filling in the gaps in node support, along with developing a proper C.I. regime for the entire toolchain.
If more than just one person is going to work on this it’s necessary to settle on some guiding principles though.
@daboe01 I agree philosophically. There is, though, a potential advantage for some workflows in running C.I. or deployement/packaging processes on a non-macOS platform. In particular, our tool chain is brittle — in part because it isn’t subject to the same amount of automated testing.
This lack of automated testing is particularly acute with those tools which are macOS-native. It’s arguable that logistical difficulties in setting up automated tests for those native tools are partially responsible for the lack of testing. Compilers and other tools are often more difficult to test, so it’s not the only reason.
I’m skeptical that having a pure Objective-J + Javascript toolchain will, alone, improve the robustness of the toolchain — but it wouldn’t hurt to have this as an objective.