projectGenerator CLI : addons.make file is altered and addons are removed if not found

[dimitre]

I've noticed recently projectGenerator CLI is actually removing addons in the case they are not found. It would be great to keep them or at least have a parameter to keep, so you still know which addons are needed even if you haven't cloned or moved to another folder before building the project. Thank you

[ofZach]

in case it's helpful to understand, the projectGenerator rebuilds your project each time starting from a template (and then incorporating your source and add ons), so there's no way to keep a missing add-on -- meaning, it doesn't parse your current project file (which is exceptionally hard to do across platforms) but only looks at the addons.make file, the src folder and anything in config.make to make a "new project file" -- this is why sometimes you can loose settings or other informant that's not conveyed with those things that are parsed. since we parse add ons to know what to add to a project, not having an add-on present is an issue and I'm not sure if there's a good solution for what you are asking for.

[dimitre]

hello @ofZach thanks for the quick answer. maybe I didn't express myself clear. sorry about that. projectGenerator is actually changing my addons.make and removing the line if the addon is not found. for example if I create an addons.make with let's say

ofxZaira

as a content, and runs projectGenerator on that folder

../../../apps/projectGenerator/commandLine/bin/projectGenerator.app/Contents/MacOS/projectGenerator -o"../../../" -t"vscode" .

it actually removes the addons.make content. I think it was a recent change in projectGenerator, it used to behave properly until recently and keep addons.make file OK even when addons were not found.

[ofTheo]

@dimitre I dug into this a bit and you are correct.

I don't think it was ever intentional to keep addons that don't exist in the addons.make. But maybe the change you mentioned was from this: https://github.com/openframeworks/projectGenerator/blame/master/ofxProjectGenerator/src/projects/baseProject.cpp#L311-L313

That was around 5 months ago. It could be fairly easy to change those lines so addons which don't exist aren't ignored.

I am not sure 100% how that would end up working with the frontend system, but it could be fairly safe to change.

[dimitre]

It would be great to keep addons.make untouched, for my usage. I use a drag and drop application to create multiple projects in multiple directories at once. after that I know which addons I should clone if any is missing.

the way it is now I loose track of needed addons because addons.make are being rewritten if I miss any addon.

[dimitre]

I think of addons.make as a recipe to build a project, and if the addon is not found in that context it should be kept as it is. Does it make sense? Project Generator CLI is actually editing addons.make and removing the missing addon. Is it desirable behavior? Thank you

[dimitre]

I can work on a PR for this one soon

[dimitre]

I would love to discuss this issue a little more. Does addons.make needs to be rewritten because it automatically adds addon dependencies to itself?

[artificiel]

paraphrasing my comment from #7464 in this context:

The GUI is better designed as it pre-parses the project (upon selection) and reports non-existing addons and warns nicely about overwriting the project settings. it's productive: if you download some project and try to PG it you'll know what addons to install.

I presume the whole workflow design considers the GUI the safeguard, and the cmdline a lower level "you-know-what-you're-doing" type thing, but perhaps the command line should nevertheless mimic the safe behaviour and not generate a project if some addons are not found? (unless some --purge or --preserve flags are passed, giving the user control over the re-writing).

in case of re-generation the addons.make would still need to be re-written (as @dimitre mentions some addons add addons as dependencies).

so, if cmdline detects a missing addon or dependency:

• default: abort; log missing addons
• --purge: re-write, without missing addon [current behaviour]
• --preserve: re-write, but re-insert a reference to the missing addon

(I am not sure about --preserve but it seems to be the expectation of @dimitre — is it useful vs a default abort? it seems it would either create broken projects, or carry superfluous addons?)

[dimitre]

I think we should have an untouchable recipe to generate the project later, as in other projects cargo does for rust, platformio.ini for platformio so the project can be generated in a later time, or by another programmer that don't have to pickup in code which addons to include again

[artificiel]

ah yes, in that regard the PG design comes after the Makefile workflow where addons.make are exactly that, untouchable recipes (you simply add/remove lines to add/remove addons, and run make). so the PG tries to facilitate that edition, plus generating the IDE files, but by doing that unfortunately blurs 2 responsibilities with addons.make: the recipe-intent, and the required file for the Make toolchain.

indeed, a higher-level declaration of what the project is (and include features like post-process or asset download) would be great, but that should be addressed as part of a whole toolchain design (as it will probably change things to the point that this issue becomes moot).

my comment above reflects on the issue at hand (silently removing not-found addons from addons.make) vs cmdline PG behaviour and augment it's robustness in protecting existing projects, while constraining the required development effort within the logic that's already in place.

so you must decide if it's an issue to be fixed, or a criteria to add to the design specs of the next toolchain/utility system!