async. The latest Acorn has a poor man type of plugin architecture that can be used to extend the parser. But it is very dependent of the internal workings so not very good at extending more complex things like we do with the Objective-J language. It is also hard if not impossible to extend the Tokenizer with that plugin architecture. The Tokenizer is modified in our version to implementation our preprocessor. It is not built like a regular preprocessor that "preprocess" the file and creates a new file that is then compiled. It is implemented as a Recursive Token Transformer. It will transform tokens on the fly to the "preprocessed" result. This allow it to be very fast and only do one scan over the source file when compiling.
tests.jsat https://github.com/mrcarlberg/acorn. Should be nice if we could get your problem as a test case too.
@mrcarlberg afaik we can build and test XcodeCapp using github actions too. I began looking at this several months ago. From what I saw, the oldest support OS is High Sierra.
Does limiting XcodeCapp support to macOS 10.13 to fit Github’s CI pipeline cause problems for us?
XcodeCloud is available now too, but that is tied to individual Apple IDs - Github Actions seems the better choice.
I continue picking away at the problems in XcodeCapp as time permits and will set up CI actions for it.
#importstatements because Objective-J so far as I know does not really understand
#import. Technically—Objective-J should never see my
#importstatements because these are hidden behind an
@mrcarlberg This question is probaby for you (but anyone with large app experience should chime in)…
Our main app is best approached as a plugin host, with something like 1 1/2 dozen modules which a user can activate. They all have content displayed in the host app, in a defined subview.
Until now, all the modules have lived in a Modules bundle in the main app, each with their own sub-bundle. This works, but it is a subtle invitation for unwanted coupling.
Moving the plugin bundles to the Frameworks folder is more elegant, but they are under active development, including xibs. XcodeCapp won’t see resources in those bundles to recompile (especially xibs). Adding the Framework bundles as separate Xcode projects runs into temporary path permission problems with nib2cib.
It looks as though the only proper way to do this is to move the bundles to their own projects and git repositories.
Thoughts on best practices for large scale development and modularity?
objj2objcskeletonmanually or with a simple bash script.
The OS setup is absolutely standard (Monterey hardly allows anything else). XcodeCapp appears to have been designed with the intent all xibs are stored in the main bundle’s Resources folder and doesn’t seem to behave well if not. Keeping xib resources separate from their associated code resources is increasingly a problem for managing the app, as it grows. Using folders in the Xcode sidebar as logical groups is one answer to that, but, as you point out, XcodeCapp is ill-behaved wrt Xcode project files (in some circumstances). That can, should, and will be fixed, but this app has also grown beyond the point where a monolithic project structure is appropriate. It is also just a nuissance to keep one or more terminal windows open to watch and compile nibs. And also to create Objective-C matching class definitions. And Xcode doesn’t have an integrated terminal capability.
Packaging as frameworks, in the Frameworks folder, seems the best approach. At the moment, the modules are under active development - for refactoring. I’m also somewhat concerned about managing imports in the frameworks scenario - there are currently cross-dependencies, and it’s not yet obvious how those will be sorted out.
An allied problem is that I insist on far more separation of concerns into individual files than most people probably do, with smaller controllers for many, if not most, individual sub-views. That’s before getting to datasources and delegates. It’s reached the point these really should be packaged directly with their associated xib assets. Some will suggest avoiding xibs altogether - my experience is it’s very difficult to get a visually polished result going that route.
Simpling moving the module bundles into the Frameworks folder has resulted in jake build problems though. It looks to me as though, as frameworks, they need to be kept entirely out of the main app, built separately, and the build artifacts symlinked or copied in. I assume the reason XcodeCapp allows adding multiple projects which are actively watched is to accommodate just such an approach. I was hoping someone might actually have experience with such, but it seems not.
For the moment, staying with the monolithic project structure is workable. A single module is currently being factored out into a separate app, and that can be used as a base to work back upwards in complexity.
One thing I’ve noticed is the monolithic on-disk structure of this app has negatively influenced coupling of the constituent parts - it’s more rigid than need be.
It’s probably time to revisit Nuage’s project structure - it’s of the scale I envisage this app soon reaching and perhaps it offers some guidance.
Info.plistfile. This allows a deep structured project to be compiled in the browser.
@mrcarlberg I had come to the same conclusions over the last few years. The best approach available now has been to use Xcode’s sidebar groups to provide useful organization. It works, but one must be careful to not select ‘Group with folder’. I had noticed #2963 when it was posted, but failed to grasp its significance. fwiw, there has long been a Ruby gem to synchronize Xcode’s virtual folder with the on-disk structure: https://github.com/venmo/synx
An analagous automated tool would nicely complement #2963
Anyone able to describe in detail how an app built for release bootstraps itself? I’m in the process of hardening ours, starting with prohibiting everything, then specifically allowing the pathnames required by the app.
Strangely, one of the first URL requests is for main.j, which isn’t a file in the Release build artifacts, despite having a reference in index.html. Having trouble understanding where the request for main.j originates - although I’m guessing it’s a fallback built into the Objective-J runtime file.
Insight welcomed. It will also help in process of defining the offline operation requirements.
Frameworks/Objective-J/Objective-J.jsis read and executed. It will setup the Objective-J runtime.
./Info.plistis read and parsed to get stuff like path to main file (usually
main.j), is it prebuilt etc...
@importthen read each of the imported files.
mainfunction. The function is called.
In depthsheader from the main wiki page :smile: : https://github.com/cappuccino/cappuccino/wiki/Bootstrap
Build/AppName.buildis, as you say, used in the build process. It stores all the compiled source files before the common source file is being created. It is not removed after the build process as it is also used the next time you build to only recompile the files that are changed. You can remove it by doing
jake cleanor just remove from command line with
rmor from the FInder.
@mrcarlberg Do you know if the Jakefile syntax is sufficiently close to that of a Makefile for a make linter to be usable?
I’ve just had a modification to the standard Jakefile in a project which unintentionally introduced invalid characters. Running
jake produced very unhelpful feedback — it complained the problem was in the Cappuccino’s narwhal bootstrap.js file :-(
Perhaps I hadn’t had my morning coffee, but it took an hour for the eureka moment when I realized the problem was in the Jakefile itself.