Project Generator Revisited - ofGen

[dimitre]

I'm in the process of rewriting Project Generator (CLI) and I'll share some ideas and thoughts here.
the idea is having a CLI app not depending on OF, so it build faster and can be compiled in a script in installation process.

I think the simplified lists of tasks are:

Project

adding the project src and paths, and additional folders to the project

Addons

Parse the list
check existence in local folder, and then in OF Addons folder
getting all the correct folders, the common ones and per platform ones (this is tricky because there are some variations on addons files organizational)
Separate in different lists of files according to usage (header files, source files, include paths, static libs, dynamic libs, xcframeworks/frameworks)
Parsing addons_config.mk in a simple key:value structure, like a map, without validating anything.
adding only the keys belonging to meta, common, and desired platforms.
filter all the folders list, applying exclusions and removing undesired files per platform (headers, sources, etc)

Templates

Until here we didn't even touch templates. so all information is already gathered independently of the template to be applied.
now we choose the templates, the list of files to be copied, the replacements, the renaming.

[danoli3]

If you can clean it up and start developing out the return status codes in the format be awesome.

A hypothetical Electron replacement will probably depend on oF so too much about removal of oF depends though but the actual parsing stuff should be focus and generation of rework. If you wanted to make it faster maybe we could build actual final static libraries (rolling on latest) for core on core and add release: macos/windows/linux with static library of Core as a release binary to link for the PG project after a download, action on of.yml on each at the end release binary

We still gotta figure out how to integrate CMakeList generation too (once we merge in CMake core compiling). See Android PR for example.

[dimitre]

return status codes?

[dimitre]

scanFolder, I think it is covering everything needed for addons.
suggestions are welcome:
https://github.com/dimitre/openFrameworks/blob/ff89b68cd24d3774bcd55706948bd497aecc97fd/ofGen/src/addons.cpp#L12

[dimitre]

I have the first version of ofGen (provisory name) working now.
wondering about the best way to have it working on path.
for now the idea is making a symlink to /usr/local/bin with a install script (will ask for password)
the good thing about this approach it doesn't add multiple entries on path and it can be uninstalled with another script.

[dimitre]

Platforms and Templates (naming)

now in PG there is a confusion between platforms and templates. like

[notice ] target platform is: [osx]

maybe historically they were the same, but now we can have a build system or IDE for multiple platforms, like VSCode, so maybe calling it template and separating from platforms is important.

[dimitre]

Treat project as an addon

it would be great to have all addons possibilities on project generation, like adding macOS Frameworks, custom cflags, etc.

[dimitre]

I'm now working on a yaml template where one can add defines, (soon cflags and everything else) per project. It will add entries according to the specific template. From my fork Make is one more template alongside XCode, so generator will write config.make to reflect recipe options, and make is not the recipe anymore. One can make a pure xcode template without any Make files for example.

ofpath: ../../..

addons:
  - ofxMicroUI
  - ofxTools
  - ofxNetwork
  - ofxAssimpModelLoader
  - ofxScenes
  - ofxParagraph
  - ofxSmartFont
  - ofxFontStash2
  - ofxTweeny
  - ofxMath
  - ofxVideoWriter
  # - ofxSyphon
  # - -b of_head [email protected]:astellato/ofxSyphon.git
templates: [macos, zed, make]

defines:
  - NANOVG_GL2_IMPLEMENTATION

in config.make

PROJECT_DEFINES = NANOVG_GL2_IMPLEMENTATION

in Project.xcconfig

USER_PREPROCESSOR_DEFINITIONS=NANOVG_GL2_IMPLEMENTATION

[dimitre]

Electron alternatives.

Tauri? Neutralinojs?
Maybe a c++ direct web framework, so we can have the UI in a browser but the backend in a c++ app?
It would be beautiful to have a TextUI console cross platform app, like maybe using https://github.com/ArthurSonzogni/FTXUI

[2bbb]

@dimitre

I understand that Tauri and Neutralinojs are lightweight and great, but compared to Electron, their rendering engines must rely on each OS. This means that the cost of frontend implementation would be higher than with Electron, where you only needed to check in Chrome.

However, I’ve been away from frontend development for a long time, so I’m not sure how much effort is needed nowadays to account for differences between browsers. (I really hated the word “Internet Explorer.”)

If this is no longer a significant burden, please feel free to ignore my comment. 😊

[dimitre]

Great! I suppose Electron bothers me more because I have a slow internet connection in a rural area haha
But anyway I'm not using projectGenerator frontend in the last years.
I started using a drag and drop application invoking PG command line directly, so it was easy to regenerate projects. After that I missed to have a recipe so the project could be reproduced later (addons.make is not a good recipe, it is rewritten by pg)

[dimitre]

I now thing a better option would be using directly some webview library to make ProjectGenerator frontend, like
https://github.com/webview/webview
or
https://github.com/saucer/saucer
and I think the browser differences will be very minimal, just simple forms + css

[danoli3]

ofxImGui should be likely be the choice as the style is highly customisable and generic and used in across the c++ developer ui. Open to other uis but it’s just so good and runs on all targets right now. ImGUI is high performant. The ui can then trigger events and scripts directly. In currently experimenting with it for apothecary see my Sage. (For calling scripts). Check that out Dimitri We need to get the project generator fixed Then I’ll merge Android

…

On Wed, 19 Feb 2025 at 2:18 am, Dimitre ***@***.***> wrote: Great! I suppose Electron bothers me more because I have a slow internet connection in a rural area haha But anyway I'm not using projectGenerator frontend in the last years. I started using a drag and drop application invoking PG command line directly, so it was easy to regenerate projects. After that I missed to have a recipe so the project could be reproduced later (addons.make is not a good recipe, it is rewritten by pg) — Reply to this email directly, view it on GitHub <#8261 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGK2HHOUKCZUKPCRHHIX5L2QNFMTAVCNFSM6AAAAABV3ZAZKCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTEMRTHAZTAMQ> . You are receiving this because you commented.Message ID: <openframeworks/openFrameworks/repo-discussions/8261/comments/12238302@ github.com>

[dimitre]

Yeah this would be a great alternative to projectGenerator frontend. it could be compiled on user machine so no worry about translocation

[dimitre]

in ofGen now it is easy to append automatically make additional lines, so I'm using to work with newer linker / compilers per project

make:
  - PROJECT_CXX = /opt/homebrew/opt/llvm/bin/clang++
  - PROJECT_CC = /opt/homebrew/opt/llvm/bin/clang
  - PROJECT_LD = /opt/homebrew/opt/llvm/bin/clang++ -fuse-ld=lld