3 Jun
2008
3 Jun
'08
11:11 a.m.
"Stefano D'Angelo" <zanga.mail(a)gmail.com> writes:
I dont see what you will do within those global
initialization/finalization functions. That thing needs to be something
not platform specific.
Well, I for example would use them with NASPRO to fill the plugin with
all effect descriptors (don't know yet how to do with RDF/Turtle, but
I'll find a way).
You need absatraction for defining global constructor/destructor in
shared library. As Larsl already said, you can use some C++ tricks (like
constructor of global object), for this. In my vision, such thing is
bound to creation of shared library file, this is why I mentioned
libtool.
Interface to SLV2 (-like) library should definitively allow modification
of directory list.
Which kind of modification?
* get list of lv2 plugins (extracted from LV2_PATH by slv2)
* modify that list (add/remove directories)
* (maybe) get path of directory where plugin resides
--
Nedko Arnaudov <GnuPG KeyID: DE1716B0>
> #7. Global
explicit initialization/finalization functions for more
> exotic platforms (they wouldn't harm, so why not having them).
I still dont get what is the use case for this.
Both on the host side and on the plugin side, no need for #ifdefs to
define initialization/finalization functions and maybe support for
exotic platforms not having them. This can be made as separate thing that can be
reused for other things too. The same way libtool is asbtraction to
shared libraries.
? > #8. Rules
to find plugins possibly platform-specific and outside of
> the specification; possibly one compile-time valid path.
AFAIK, this conficts with "LV2 spirit". Why one needs this? If the goal
is to avoid RDF Turtle, this shouldnt be issue with proper helper
library for hosts. Still such feature could be implemented in such a
helper library.
Nope. I mean there should be platform-specific rules to get the list
of directories containing shared object files and possibly there
should be a fixed path to check on each platform, known at compile
time.