Setting up KDevelop project for a Maya plugin

kbrown · 2007-03-31 14:33:10 UTC

Title pretty much says it. What do I need to do to be able to compile maya plugins using KDevelop?

Carina · 2007-04-01 06:46:47 UTC

I’ve used KDevelop for this in the past, set it up as a Qt project, and then edited the Qt project file to set it up properly for maya plugins. Last time I used it was for a Maya 7.0 project but I’d assume that the principles still hold. I’ll have a look to see if I can dig up an example maya qmake project file for you if you want?

Note that I’m sure there are other ways of setting kdevelop up for it, but as i’ve used qmake files before that was what came easiest to me.

kbrown · 2007-04-02 11:54:44 UTC

Thanks for the tip. Looks like there something else I need to sort out first as I can’t even compile (manually) the simple hello world example in the docs in my fairly freshly installed FC6, which I’m starting to dislike. So far FC6 has given me the most headaches of all the fedoras i’ve tried…

UrbanFuturistic · 2007-04-02 13:53:06 UTC

Hmmm, how often I see “Fedora Core” and “headaches” in the same sentence.

It’s probably not your problem though. What you need to look into for such a project is what compiler options you need, what linker options you need and so on. For example, if you’re programming a plugin, I would have thought that would be created as a shared object so the best thing to do would be to create a project for that and make sure the linker includes all the requisite libs.

kbrown · 2007-04-02 15:48:47 UTC

Yes. I already tried quite a few ways (I’m not a complete noob with linux and c++). My gut feeling is that there is some incompatibilities with Maya API and the current gcc version I got or something similar.

Anyway, this can wait. It’s nothing important. Just wanted to quickly try out an idea I had but it’s an obsolete one by now (solved another way)

I’ll have another look when the need arises again

kbrown · 2007-04-02 16:10:17 UTC

Eheh… and 15 mins later after installing compatibility versions (3.4) of gnu c and c++ compilers… drumroll… it compiled

kbrown · 2007-04-02 17:25:44 UTC

And finally after noodling around I was able to get everything to work through KDevelop as well. I’ll write the details some other time. Need to first recap what exactly I did as it wasn’t so straight forward (to me at least)… Used (vaguely) this as my guide:

http://ksiezyc.net/en/articles/kdevelop.html

UrbanFuturistic · 2007-04-03 05:32:36 UTC

Another reason to use the recommended versions as much as possible so far as I’m concerned, and another example of how Linux is just not ready. Shame really seeing as I love using it all the time myself but it’s such a headache unless you know your way around it quite well (keeps further eye on Haiku).

nurcc · 2007-04-03 07:44:15 UTC

Although to be fair, it’s more of an inherent problems with having compilers and libraries of different versions. For example, I wouldn’t recommend anyone try to compile plugins for Maya for windows using a different version of MSVC than was used to build Maya. One problem is that MSVC changes the iostream implementation and other libc stuff every single version, making the objects binary incompatible. There can also be problems with doing inheritance and having different vtable pointers for the same object type, but Maya avoids all of those issues through MObjects and function sets.

I think in general programming tools are very poor, considering how many programmers use them.

kbrown · 2007-04-03 17:08:32 UTC

Here’s (hopefully) what you need to do in order to compile maya plugins with KDevelop under FC6.

In addition to the standard development stuff you need few compatibility packages. These can be installed by running (as root) the following command:

yum install compat-gcc-34 compat-gcc-34-c++ compat-libstdc+±33

Launch KDevelop. This is where it gets a bit hairy as the settings seem to be scattered around in many places.

Create a new project (C++ / Simple Hello world program). I’ll call mine “mayaPluginTest”. As we’re not really interested in compiling a binary executable we can ignore the auto-generated “mayaplugintest.cpp” and everything in it. Just leave them there for now.

First thing to do is to go into Project->Project Options->Configure Options. Under the tab labeled “C”, in the “Compiler command (CC)” field, type “gcc34”. Next go to the “C++” tab and type “g++34” in the “Compiler command (CXX)” field. Hit OK (you can skip the Re-run configure).

Next go to the AutoMake Manager (one of the tabs on the right). Right-click where it says “src” in the upper part of the panel and choose “Add Subproject”. Enter the name of your plugin and hit OK. I’ll call mine “myPlugin”. Find the “myPlugin” sub-project under the “src” in the upper part of the panel. Right-click on it and choose “Add Target”. Set “Primary” to “Program” and “Prefix” to “noinst”. Enter the file name of your plugin (e.g. “myPlugin.so”) and hit OK.

Right-click on the “myPlugin” sub-project under the “src” in the upper part of the window again and choose “Options”. In the field in the middle (CXXFLAGS) type in your compiler flags (e.g. -O3 -pthread -pipe -D_BOOL -DLINUX -DREQUIRE_IOSTREAM -mcpu=pentium4 -Wno-deprecated -fno-gnu-keywords). Go to the “Includes” tab and use the “Add…” button to add all your include directories outside the project. You will want to retain the “-I” in the beginning of the path (that’s capital I as in Iffy ;)). You definately need to have “-I/usr/aw/maya/include” and probably “-I/usr/X11R6/include” in the list. Hit OK.

In the lower panel of the Automake Manager, right-click on the myPlugin.so and choose “Make Target Active”. Right click on it again and choose Options. Under the “Flags” tab, in the “Other” field, type in your linker flags (e.g. -L/usr/aw/maya7.0/lib -shared -O3 -pthread -pipe -D_BOOL -DLINUX -DREQUIRE_IOSTREAM -mcpu=pentium4 -Wno-deprecated -fno-gnu-keywords -Wl,-Bsymbolic). I couldn’t find a more suitable place to put in the maya library path so I put it here. Go to the “Libraries” tab and using the the “Add…” button add the actual libraries you want to link against. Again you want to retain the “-l” in the beginning of the name (that lower case l as in lost ;)). I added -lFoundation and -lOpenMaya. Hit OK.

Right-click on the myPlugin.so again and choose “Create New File”. Enter the file name (e.g. “myPlugin.cpp”) and hit OK. Double-click on the myPlugin.cpp and you’re ready to start coding.

Here’s the sample hello world from the docs:

#include <maya/MSimple.h>
 #include <maya/MIOStream.h>
 DeclareSimpleCommand( helloWorld, "Alias", "7.0");
 MStatus helloWorld::doIt( const MArgList& )
 {
 	cout << "Hello World
";
 	return MS::kSuccess;
 }

Build->Build Active Target should compile and link your shiny new plugin (be sure to run the configure first).

That’s it. Easy and straight forward, huh?

gga · 2007-04-03 20:37:33 UTC

While your first statement is correct, your second one is FUD. Windows suffers from much worse problems with its official compiler and libraries, having broken binary compatability on each and every major version (v6, v7 and v8). Worse, they even broke binary compatability of STL between v6 and v7 in a big way, as v6 was shipping with a broken STL with no namespaces.
Version 8 of the microsoft suite is probably one of the worst things now, as Microsoft has now added the nightmare that is “manifests” – a completely unneeded feature, and it is now also pushing to depreciate some standard C functions that have been available for years (printf, etc) and most POSIX functions, without much justification. And that’s what you get for a paid (and costly) product.

In comparison, the gcc team has broken its ABI only once in a similar time frame: from 3.2 to 3.3/4. gcc4.0+ remains backwards compatible with stuff compiled with 3.4. While the STL has changed on linux on each new version of the compiler, it has remained binary compatible, as it has always shipped with namespaces. And to top if all off, you get it all for free and open sourced.

UrbanFuturistic · 2007-04-04 05:25:17 UTC

Crikey! To be perfectly truthful with you I haven’t used Visual Studio products in some time as I aim for cross platform capability and, while unfinished, Dev-C++ 4.9.9.2 does a solid enough job for me. I suppose I expected, what with Windows itself being such an unchanging base platform in terms of backwards compatibility, that it would somehow be better in this respect.

At least when GCC breaks old code, it’s most often because this old code broke certain programming rules that GCC no longer allows it to break for various reasons including security issues, limitation of memory leaks and generally the kind of programming that leads to stuff breaking in execution. It’s also good to see that there are compatibility RPMs that sort any problems out but really it would be nice if they were more obviously accessible.

Carina · 2007-04-04 05:42:39 UTC

I don’t see how you can say that Linux isn’t “ready” because a particular compiler version is recommended when compiling a project. While updates are released very frequently, “older” versions still remain readily available on most distributions. If old versions magically sort of disappeared you would have a point, but as they are still there and available, and can coexist with other versions quite harmonically, I don’t understand how it poses a problem.

Carina · 2007-04-04 05:44:57 UTC

Any chance you fancy posting this information on the wiki?

UrbanFuturistic · 2007-04-04 08:47:03 UTC

Mainly it was in reference to the lack of backwards compatibility that is often found in Linux distros. Now, while this is being worked on, it’s not finished yet and it’s still not entirely unusual to find you can’t have two different programmes on one installation because they demand different versions of the same libraries.

This is particularly a problem when trying to run certain older python scripts under blender as a seperate version of Python has to be compiled in a seperate place and a shellscript setup so as not to interfere with systemwide settings that other, often essential, software depends on. It’s good to see, as I was unaware, some backwards compatability in GCC versions with Fedora Core 6 but it is more the exception than the rule and until ‘dependency hell’ is dealt with in a more widespread manner, I don’t consider Linux to be truly ready.

kbrown · 2007-04-04 09:43:43 UTC

Maybe at some point when I have the time and the energy. Might take some screenshots as well. I’m super busy at work at the moment so if anyone else wants to do it, I wouldn’t mind ;).

Carina · 2007-04-04 10:19:53 UTC

The same is certainly true for Ubuntu (and I believe SUSE as well) and not only with regards to GCC but many many other compilers/libraries I’ve had to use. I doubt other distributions haven’t caught onto it as well…

Carina · 2007-04-04 10:22:03 UTC

Righto, was worth a try Might do it myself if I have a chance in the next few weeks. Thanks for taking the time to write up a tutorial in the first place! Might have a quick check and see how it compares to what’s needed in Ubuntu.

CGTalk_Moderation · 2007-04-04 10:22:04 UTC

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.