[LV2] Bikeshed: include paths

Stefano D'Angelo zanga.mail at gmail.com
Tue Oct 6 09:59:14 PDT 2015


2015-10-05 15:48 GMT+02:00 David Robillard <d at drobilla.net>:
> LV2 currently uses header include paths based directly on the URI of the
> relevant extension.  This is nice because the same convention can apply
> to all LV2 specs (including non-official ones) without any possibility
> of clashing.  However:
>
> 1) The official LV2 namespace is unfortunately deep and sloppy.
>
> 2) Working in a source tree structured this way is unpleasant.
>
> Accordingly, I am thinking of changing the structure used for the
> official headers to e.g.
>
> #include <lv2/atom/atom.h>
>
> where "lv2/" is reserved for LV2 itself (as usual with C libraries).
>
> This might be a good time to change so that headers are installed with a
> versioned directory to allow for parallel installs,
> like /usr/include/lv2-1.0/lv2/... This is the usual best practice for C
> libraries, but since LV2 isn't a library I am not sure there is a point.
> LV2 isn't allowed to break, so if it did, it would be lv3 anyway?  That
> said, *having* to provide an explicit include path avoids some "what am
> I building against?" confusion.
>
> Downside: if the source tree is restructured this way, code using the
> current/old #include scheme can no longer be built against the LV2
> source distribution (without building it first).

Breaking the world for the sake of making a few #include directives
more pretty doesn't sound decent to me.

Breaking the world to get rid of old crap (e.g., connect_port(),
control ports) would be interesting, but I doubt any user/developer
wants that. However, if it is the time for it, I'd like to sit at the
table and contribute my part.

P.S.: yes, I am still alive, just not kicking... and I still care somewhat.

-- 
Stefano D'Angelo
http://sdangelo.github.io/


More information about the Devel mailing list