Vuo SDK with libc++ settings

Feature Requests
,
1

Hey guys,

I don’t know if you have been watching libcinder’s latest release or not. I think they progressed amazingly for this release. I wanted to have a go with combining Vuo and libcinder . With the target of a two-way relationship between these two, I want to start with the simpler one “having Vuo compositions run in Cinder”. I was checking out the docs and I saw that the llvm compiler settings for the SDK is “libstd” and “C++98”, the thing is libcinder now only supports “libc++” and “C++11/14”. My question was if it’s possible to run Vuo with Cinder’s llvm settings or not?

Thanks,

2

I tried building the VuoPluginApp example from the Vuo SDK using libc++ and C++11, and ultimately got stuck. Looks like it’ll require some changes to the Vuo SDK.

The first problem was some warnings about types being narrowed, which I silenced by adding -Wno-c++11-narrowing to the project’s Other C Flags. (We should fix the underlying problem.)

The second problem was some undefined symbols: llvm::createPrintModulePass and llvm::createPrintFunctionPass. These are coming from the LLVM library that is a dependency of the Vuo SDK. I’m guessing it’s because the LLVM library was built with libstdc++ and these functions fall under the category of things incompatible with libc++.

Kino, let us know if you manage to get any further in building a Cinder + Vuo project.

This is something we’d like to get working, since more and more projects are moving to libc++.

3

Thanks Jaymie,

I would love to get this to work. I really haven’t played with Vuo SDK yet, I just saw that the instructions kind of interfere with Cinder’s and I thought to ask if anyone has solved this or not. For me the end goal would be not only to have Vuo in Cinder but to make Cinder work in Vuo. Vuo has this great multi-threaded node based system already implemented and also it has its focus on things like making plugins and VJ app support (which is totally not focused by Cinder). What would be great ultimately is to have libcinder as a library module for Vuo (With all the right type converters between libcinder and Vuo’s types and a system for sharing Context data between the two), this will make it really easy for people to write Vuo nodes with libcinder and also paves the path for a node-based libcinder. Something like a more mature version of what Vade did with Openframeworks.
I’m pretty keen to put my time on this (although I’m quite busy with other stuff these days) but the vision is exciting enough to get me going. I’ll start and will report any progress I have on the way.

Thanks again for your help Jaymie

4

BTW Jaymie now that I have your attention here, I wanted to ask if it’s possible to make port types for Vuo with C++ classes. I saw that it’s doable for C structs but didn’t see any mention of classes with defined methods. Can you tell me how I can make this work (I know it’s maybe too soon for these kind of questions but wanted to know anyways).

Cheers

5

Ok I got LLVM and ready to try for a libc++ build. I also got Vuo’s sdk, just one question: Has the SDK changed much recently? I could only get version 1.0.1, I hope that’s fine.

6

What would be great ultimately is to have libcinder as a library module for Vuo (With all the right type converters between libcinder and Vuo’s types and a system for sharing Context data between the two), this will make it really easy for people to write Vuo nodes with libcinder and also paves the path for a node-based libcinder.

Cool. I guess libc++ would be less of an issue there, since the Cinder library module could avoid having STL types in its interface.

I wanted to ask if it’s possible to make port types for Vuo with C++ classes

Yes. In fact, the VuoList port types do that.

There’s a trick to it, because the port type has to be exported as a C (not C++) symbol. I’ll give VuoList_VuoInteger as an example. This port type is actually a std::vector<VuoInteger> *. But it’s typedef’ed to something C-friendly in the header file.

In VuoList_VuoInteger.cc, we cast between VuoList_VuoInteger and std::vector<VuoInteger> *. For example:

VuoList_VuoInteger VuoListCreate_VuoInteger(void)
{
	std::vector<VuoInteger> * l = new std::vector<VuoInteger>;
	...
	return reinterpret_cast<VuoList_VuoInteger>(l);
}

VuoInteger VuoListGetValue_VuoInteger(const VuoList_VuoInteger list, const unsigned long index)
{
	std::vector<VuoInteger> * l = (std::vector<VuoInteger> *)list;
	...
}

In VuoList_VuoInteger.h, we typedef to something C-friendly. We used to do:

typedef void * VuoList_VuoInteger;

But then we realized that this messed up type checking (e.g. the compiler wouldn’t catch when we accidentally passed VuoList_VuoReal to a function that expected a VuoList_VuoInteger), so now we do this more complicated thingy:

typedef const struct VuoList_VuoInteger_struct { void *l; } * VuoList_VuoInteger;

If you want to see the whole files, you can download the source code. VuoList.h and VuoList.cc are in type/list. If you go into that directory and run ./generateVariants.sh VuoInteger:0, it generates VuoList_VuoInteger.hh and VuoList_VuoInteger.cc.

Has the SDK changed much recently? I could only get version 1.0.1, I hope that’s fine.

See the SDK section in the 1.1.0 release notes. If you’re concerned about nodes/modules built with the 1.0.1 SDK being compatible with Vuo 1.1.0 and haven’t bought the upgrade, you could try them in with the free trial version.

7

Switched from libstdc++ to libc++. Implemented in Vuo 2.0 beta.