includeURLsare the paths to the current working directory
/Users/gtavares/Desktop/Browser/gtktestand 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/runtimenode module. I will look into why this is happening.
includeURLsbut could be added manually with the environment variable
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.
imagesizeneeds to be replaced in the node version — it is used by
nib2cibif a xib contains images.
imagesizerequired 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?
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’ ;-)
flattenis not yet supported in the Node version but
fontinfois native Mac OS tools and is only needed when running
nib2cibas you say. The need to convert
fontinfoto 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 objjand it does now work. The update is in the
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:
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
imagesize be left as-is, or should platform-agnostic versions be substituted, leaving open the option for eliminating
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.
Jakefileto fit my structure!
jake buildI get this error
bach@mbp14 _cappDevelop % jake build (in /Users/bach/Library/Mobile Documents/com~apple~CloudDocs/Bach/Projekte/Websites/WWW-michaelbach-de/ot/ang-Bourdon/_cappDevelop) options.args: Resources/MainMenu.xib,/Users/bach/Library/Mobile,Documents/com~apple~CloudDocs/Bach/Projekte/Websites/WWW-michaelbach-de/ot/ang-Bourdon/_cappDevelop/Build/Debug/capp/Resources/MainMenu.cib options.args.length > 2, will crash
jake releasethe Resources folder remains empty.
options.argsoutput does not appear in the user where everything works. Is the path possibly too long?
index.htmlI only use relative paths, and don't use spaces. But somewhere during the compile process the path is expanded to full length, and near its "upper end" (see above) there sits "Mobile Documents". So I don't see where I could insert a soft link.
jake releasethere and find the same crash. So unfortunately this does not help. Of course I could move my actual tree with all of ~100 Capp. programs out the of iCloud tree, but would loose synchronising across machines (unless switching to some other offer, with its own problems). So here's to hoping it's only very little work to fix the Node branch to make do with spaces in path names (escaping or only use relative paths). Would love to fully switch to the Node branch!
(in /Users/bach/…; after the second
options.args: … will crashoccurs, and this is generated within nib2cib in a parsing context. Of course, once that is fixed, there might be more places later… or not… :)
nib2cibwith one or more spaces in the path to the
.xibfile. I have made a fix in this branch: https://github.com/mrcarlberg/cappuccino/tree/nib2cib_space_in_path. You should be able to install that version with the instructions from the wiki under the headling "... from source ....". Use above path to the repository and the branch