Add include_directories to pugl_dep.

[mfisher31]

Had more errors on Mac. The OSX apps were reaching one directory back to far ('../../../../include') to a non-existent folder. I assume include is public headers, so I added it to include_directories on the pugl_dep object. Fixes these mac errors and also probably good when used as a subproject.

pugl| subprojects/pugl/examples/pugl_cairo_demo.app/MacOS/meson.build:4: WARNING: include_directories sandbox violation!
The project is trying to access the directory **'../../../../include'** which belongs to a different
subproject. This is a problem as it hardcodes the relative paths of these two projects.
This makes it impossible to compile the project in any other directory layout and also
prevents the subproject from changing its own directory layout.

Instead of poking directly at the internals the subproject should be executed and
it should set a variable that the caller can then use. Something like:

# In subproject
some_dep = declare_dependency(include_directories: include_directories('include'))

# In subproject wrap file
[provide]
some = some_dep

# In parent project
some_dep = dependency('some')
executable(..., dependencies: [some_dep])

This warning will become a hard error in a future Meson release.

subprojects/pugl/examples/pugl_cairo_demo.app/MacOS/meson.build:1:0: ERROR: Include dir ../../../../include does not exist.

[drobilla]

Yeah, my bad, pugl-as-a-subproject tends to rot still, since I haven't yet incoroprated it into lv2kit or my personal subproject tree.

Fix LGTM, thanks. Merged as c3bc53d (same, but with some whitespace and the mangled commit message fixed).

[mfisher31]

No problem. The subproject has been getting tons of attention in LVTK lately. Think I'm going shift focus to high performing customizable GUI's in 3.0: https://github.com/lvtk/lvtk/tree/main/include/lvtk/ui .

[drobilla]

Nice! I'll check it out

[mfisher31]

With a major version bump: could also be a chance to finish offical LV2 c++ bindings (if you even want that). LVTK could then just expand upon official templates.

[drobilla]

It's a thing I'm certainly thinking about, although I'm not sure about the details yet. Still trying to get things solidly maintained and moving forward before adding stuff, but that phase is thankfully almost done now...

As a smaller step, we could bring the project under the umbrella of the lv2 organization on git* if that appeals to you. I think it would be nice to have more projects under that banner, and individual projects can more or less remain as they are maintaner- and other-wise. For lvtk, the build system and license already match, so it would be pretty easy to take advantage of the CI infrastructure and whatnot as a concrete perk. The Windows and Mac stuff runs on my personal machines, so aren't quite as available as Gitlab-hosted Docker images, but they're usually online and I don't mind.

[drobilla]

Re: the bindings, IIRC I liked the direction you took there and it seemed pretty close to being suitable as "official" bindings, but it's been a while. I'm just coming out of vacation mode at the moment, but I'll try to take a look shortly and refresh my memory.

[mfisher31]

Yeah, absolutely: lv2/lvtk would be a great honor! As for c++ bindings, I'll keep moving forward for sure. In my mind, LVTK 3 should implement real lv2 bare bones templates and expose a higher level API with minimal templating.

I have an idea where there's a managed/internal context that owns the coder's instance class. Some kind of pipeline between UI and Plugin contexts could be established and make it really easy for users to do UI <=> Plugin comms.... and also have a built-in Widget library on par with (or better than) typical GUI toolkits.

[drobilla]

Yeah, there's some template vs runtime overhead struggles there I never really found an ideal solution to. Atoms make really easy/nice bindings annoying too, mainly because the type URIDs are dynamic. I'm still really interested in exploring standard URIDs being static to make such things dramatically cleaner and easier to use, but it's a pretty big change, and I'm not sure how to do it in a maintainable way given the modular spec (e.g. one huge enum somewhere seems... questionable? or maybe not?)

Getting a bit ahead of ourselves here though, I suppose. If you're interested in lvtk, or parts of it, or... something, moving under the lv2 org umbrella, that's great; I'll try to figure out some nitty-gritty details and take that topic up elsewhere.

[mfisher31]

It could be as simple as the big enum + a utily lv2_map_standard_uris (map, unmap) .. then suggest hosts start using it and send a data-only feature to plugins. IDK, that's my initial reaction without over thinking.

[mfisher31]

Giant enum I'm sure could easily be generated with a meson generator + python script (or something)

[mfisher31]

Oh... this method the enum serves as the key in a key/value relationship... not the mapped URI... could be misleading for plugin authors just wanting the URIDs... it's a toughie .

[drobilla]

Yeah, easy enough to generate initially. I've done it before with just a bit of command line and text editor hackery. The details are the tricky bit: prefixes are annoying, but there are name clashes, a single header somewhere having a dependency on every other extension (which are still true "extensions" and not particularly privileged except being maintained together with the core), etc