I’d like to have a way to conditionally include modules in my build, which is straightforward #ifdef everywhere but plugin.json.
I’d use this for two scenarios:
Having a prototype/diagnostics plugin that I only use in development.
Maintaining a plugin template that I can easily clone to add a plugin to the collection.
Most things are taken care of by a combination of a common base class and C++ templates for some common implementation logic I can drop in when it’s appropriate for only certain modules or widget, but there’s still a lot of boiler plate and I’d rather clone a maintained working template and building out rather than cloning an existing module and editing it down.
I never want these in a release, and I’d rather not have to manually edit these things in and out of the plugin.json around a submission to the library.
Does anyone have a simple, portable pattern that can be used in a stock Rack plugin makefile for assembling a plugin.json? Either building from individual module json fragments, or some kind of if-def would work for me.
I’ve forgotten 98% of everything I used to know about makefiles.
It would be great if there was a simple flag in the module json to tell rack to completely ignore that section. That would work for me, but I have my doubts that Andrew would go for it. ‘hidden’ doesn’t cut it for this scenario. I definitely don’t want these in the package and the modules won’t exist in the plugin.dll.
There’s two files for creating two sets of models for the plugin - you could edit these and have one (create_release.sh) for the library and another (create_dev.sh) for a pure dev build. create_all.sh in the repo is used to call both these bash files (create_XX.sh) to assemble the plugin from a template for both sets of models. You’d also have to add to these descriptions and tags.
The Makefile used is the standard one with no additions.
I just use separate plugin and a private repository for any modules I don’t want to release. I also generally copy an existing module as a starting point for any new ones. Sorry, not really much help!
I develop mine on a branch, because I want to be able to push to origin at least every day. Since it’s on a branch I don’t mind it the “experimental” things are enabled.
I’m more in the same camp as Squinky. When I’m developing something experimental, I create a git branch and do whatever I want in there, including edit plugin.json.
But if you really want to dynamically generate plugin.json as part of your build process, instead of doing it from the makefile, you can create a script that you run every time you build. That script can generate the plugin.json, then run the build as usual via makefile. You can write the script in whatever language you want, and you don’t need to know anything about makefiles.
I have various code generators that output my panel svg files and some C++ lookup tables for Sapphire. These helpers are mostly written in Python. Then I have a build script that runs the code generator, followed by running make.
I also commit all the generated files as part of my repo, so when I change a code generation step, I can use git diff to see what changed in the output. It also means that other people don’t need to run the code generator to build and install Sapphire (assuming they didn’t modify the checked-in code).
If you go down the road of a pre-build code generator step, it’s a really good idea to make it work as follows, to reduce make dependencies triggering unnecessary build steps each time.
Read the entire text contents of the current plugin.json (or whatever the generated file is) into a string variable oldText. If you can’t open/read plugin.json, then set oldText = "".
Generate what you want to be in plugin.json into a string variable newText.
If oldText == newText, don’t do anything. Exit with a success code. Otherwise, overwrite plugin.json with newText.
This preserves the existing date and time stamp on the target file if nothing has changed (which will be 99% of the time). That means your makefile won’t execute unnecessary steps.
It’s easy to manipulate and generate correct json format with Python, Node.js, or even C++ for that matter, using existing json libraries.
Without hijacking the thread too much, you can take a look at my panel generator. I found it incredibly frustrating to use a GUI editor like InkScape; it’s hard to get it to do exactly what you want – they seem actively hostile to precisely controlling the positions of things. It’s like trying to do calligraphy with a broomstick dipped in tar.
I get that. If you have a stroke, the stroke width gets included in metrics, so when you add/remove strokes, the positioning of the points is then off. I wish there was a mode to work based on the control points, not the drawn bounds. They also seem to have accuracy issues with converting between your chosen units and whatever their internal normal form is.
I do lots of simplification and fine tuning by hand in a text editor after doing general design in Inkscape.
For text on the panel, I have a scratch SVG where I generate and format the text, putting it at 0:0, and converting to path. Then I use a text editor to put it on my panel, and use transform="translate(x,y)" to position it. I’ll use the same technique for creating other complex elements that I can then shove around with a transform on the group, as a I rationalize the widgets from code with the panel.
I’ve seen people using generators like you do, and the idea is appealing, but I enjoy the immediacy of direct hands-on tweaking (and I have little interest in learning python). Helps a lot that I have SVG hot-reloading in my current plugin (both panels and widgets).