Friday, February 19, 2010

IDE-Experienced

Since I've been working on a lot of Drupal sites lately, my primary Integrated/Idiosyncratic Development Environment (IDE) has been Eclipse. The PHP editor, debugger and other tools (part of the PDT)  as well as Subversion, CVS and a bunch of other plugins make Eclipse a good choice for cross-platform development teams working on a wide range of project types. It's usually easy to set up and extend, but I did experience one problem on my Linux (FC12) laptop: Eclipse Update did not work at all, so the usual simple installing/updating of plugins by checking them off a list wasn't an option.

After some googling, I found that the problem was a bug (also here and many other places), which may or may not have been fixed on certain GNU/Linux distributions or with certain versions of Eclipse. The workaround mentioned here was the quickest fix, with one small improvement: I renamed the "eclipse" executable to "runeclipse" and named the shell script "eclipse", which calls the renamed executable. This way, all references to the original executable (think menus, .desktop files, Eclipse restarting itself) run the shell script with GDK_NATIVE_WINDOWS=true. So, Eclipse problems solved. Subversion integration worked without a hitch, and I was up and running.

The next project I'm working on is a C#/ASP.NET web application, with a heavy API of its own and plenty of library goodness to develop and integrate. The app will run on Windows/IIS, but I want to use my native desktop environment (GNOME/Linux) for .NET development. Plus, I'd really like to hack some GNOME apps, many of which run on Mono. Rather than attempting to make Eclipse run everything, I thought it was time to try out the obvious choice, MonoDevelop. Browsing the Fedora repositories (including RPM Fusion), I found the newest package available was 2.1. Since MonoDevelop doesn't maintain a Fedora package (hmm, I'm starting to see a pattern here) and I wanted 2.22, I embarked upon a good old-fashioned installation from source.

Things got interesting right away. Using the instructions from the README file in the source directory, I typed:

./configure --prefix=`pkg-config --variable=prefix mono`

First error:

checking for MONO_ADDINS... configure: error: Package requirements  (mono-addins >= 0.4) were not met:

No package 'mono-addins' found

Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix.

Alternatively, you may set the environment variables MONO_ADDINS_CFLAGS and MONO_ADDINS_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.

I already knew mono-addins was installed; I had done this earlier because I (almost always) RTFM. However, I had done it the nice, graphical Fedora/GNOME way: using gpackagekit to search for "mono-addins", selecting it and clicking "Apply". I checked just in case:


Yes, I actually make it a point to manage my system using the GUI tools provided with GNOME. After several years of remote Linux and FreeBSD systems administration using only SSH terminal sessions, I thought it was time to see how much functionality I could get out of a free desktop like a normal Windows or Mac user. It's the ultimate test for me and the feature set; I only resort to terminals when the GUI malfunctions or is missing a feature. Kind of like fisticuffs with one hand tied behind your back. More on that later.

Okay, then: man pkg-config tells me that pkg-config is a utility used to return metadata about assemblies to callers such as the configure script above. Running pkg-config --libs mono-addins returned:

Package mono-addins was not found in the pkg-config search path.
Perhaps you should add the directory containing `mono-addins.pc' to the PKG_CONFIG_PATH environment variable
No package 'mono-addins' found 

A quick check of the search path, and sure enough there was no PKG_CONFIG_PATH environment variable set. Yet pkg-config --list-all showed a long list of registered packages. Searching for *.pc, the configuration files turned up in both /usr/lib/pkgconfig and /usr/share/pkgconfig, but no mono-addins.pc. I had installed mono-addins from a Fedora repository, and confirmed that the libraries were in their correct locations. Then I checked some of the other libraries, such as monodoc:


What a surprise - the monodoc-devel package literally is just the .pc file. In fact, many of the devel packages for mono are just pkg-config files. Why package a 207-byte file separately? Who knows. I installed the devel packages for mono-addins and all the other mono and *-sharp packages, and configuration succeeded.

After this, I ran make and make install, which gave plenty of warnings but finished without error. It even installed a menu item in my Applications -> Programming list, and MonoDevelop started up quickly on the first launch. Hopefully this experience will help someone else, and I'll post more as I continue to use MonoDevelop.

1 comment:

  1. Thanks for posting about your experiences! Hopefully this will help other people to get started with MonoDevelop on Fedora.

    I know that people sometimes have problems with MonoDevelop on Fedora - the Fedora Mono packagers have some odd policies, such as shipping old alpha/beta versions of MD in stable repos, or moving all the (noarch) assemblies to lib64 where MonoDevelop and other tools can't find them.

    If you're comfortable building software from source I'd definitely recommend building Mono 2.6.1 too, because Mono 2.6+ includes a brand new debugger that's a vast improvement. However, if you do so I'd strongly advise a parallel environment to avoid conflicts with packages.

    ReplyDelete