Adding pcl::on_nurbs to PCL 1.7.1 and ROS - cmake

I have a ROS Indigo on a 64bit Kubuntu 14.04. Currently I'm facing a big issue - the missing module on_nurbs. I need it for the generation of meshes from point clouds.
My biggest problem here is the way ROS is hooked to PCL. Even though PCL is now more or less officially an external dependency the way ROS handles the situation is...Well, not very nice. I've experienced similar (maybe even the same - can't remember) issues with OpenCV - yet another dependency that was decided to be made completely external - when I decided to build it from source in order to add support Qt, OpenGL etc, which are not in the upstream packages of the library in the Ubuntu repositories. There is this thing ROS perception, which is supposed to add the glue between ROS and PCL.
The problem: Adding NURBS (part of the surface module)
What I have done so far:
I have
downloaded and built PCL 1.7.1 (the same version as the one shipped with Ubuntu 14.04 and ROS) with NURBS enabled
(1) installed PCL from source - ROS' PCL support broke
(2) replaced only the surface library (also added all the includes etc. dependencies for it and nurbs from my build) - ROS' PCL support broke
Currently I'm struggling to find out how to manually force CMake (and thus also catkin_make) to use my own version (not installed, only built). But I fear this will again interfere with ROS.
What is your advice for me in this situation? How can I proceed without yet again breaking my ROS installation? I would really like to learn how to add such missing bits and pieces - as mentioned above - I have already faced this issue once, now this and it will probably happen again.
PS for those who say "This is a ROS issue": I've already posted on ROS answers a week ago but there is still no reply and the views indicator of 11 (became so shortly after posting there - a week ago) is discouraging to say the least. The chances of any development there a week after posting the question are slim to none. I have been struggling with this issue for more then 2 weeks now...

Related

Has anyone ever built BZR 2.7.0 for Windows?

In the past we used BZR 2.6b1 on Windows for many of our professional projects.
This turned out to not be a good choice, and some of our projects suffered when we encountered some bugs in BZR 2.6, which might have been specific to the Windows version, or might not. Years passed, the bugs never got fixed, and so we began to migrating to git.
However, some of our older projects are still in Bazaar, and having returned to the Bazaar website for the first time in 2.5 years, I can see there is now a 2.7.0 release, but no Windows version of it.
I can see this message on the Ubuntu mailing-list, in which somebody has mentioned their intention to build 2.7.0 for Windows, but the mailing-list thread ends without a conclusion.
So the question is, short of compiling it myself, has anyone ever created a Windows version of 2.7.0, as an installer or archive of compiled binaries, and is it still available?
There are no Windows installers for Bazaar 2.7 as far as I know. We're likely to build installers for Breezy (a friendly fork of Bazaar that is active) on Windows once it is ready for release, but that may take a couple of months.

MONO 3.2 for Windows / Linux - Missing?

Looking for a download to MONO Runtime 3.2 but I just can find this for Mac.
See HERE
Are there no releases for Linux/Windows ?
Are there no releases for Linux?
The tarball is all you need to use/install Mono in Linux.
If what you want is that your favourite distro imports this version of Mono into its packaging system (e.g.: apt-get), then you would need to ask in the forums, mailing lists or other online resources about that distro.
Are there no releases for Windows?
First, I will ask you another question, are you sure do you really need Mono for Windows? For most use cases, Windows already bundles .NET into the last versions. Furthermore, Mono for Windows is not a top priority platform for the Mono team and may lack features or have worse performance than on Linux/Mac. Therefore Mono for windows is only really useful for certain uncommon scenarios.
If you're really interested in those uncommon use cases, then keep bugging Mono maintainers in their forums, mailing lists or IRC, to remind them to package it (it's not really a priority anymore since this platform is not something they target with their commercial offerings).
UPDATE: A Xamarin employee stated that the installer would be available when version 3.2.3 is released, and they complied with their promise because 3.2.3 has been released and the windows installer is available in the download page.

What is the difference between Lazarus and CodeTyphon

Firstly, I saw some topics about these two but weren't my answer.
I'm looking for a good FPC(Free Pascal Compiler) IDE on GNU/Linux.
There are some IDE's like Lazarus and CodeTyphon. I need suggestion to choose one of those.
I've tried Lazarus once but all windows was separated. It looks messy and not interesting.
I would like to know what are the distinguishes between these two ?
I would like to know advantages / disadvantages each of those. Thank you
CodeTyphon is a distro of Lazarus, like Ubuntu and Debian are distros of Linux.
CodeTyphon comes with a large package of components and plugins, that otherwise you would have to google and download and install.
CodeTyphon have their own idea what are stable versions and what are not stable yet for both of FPC (compiler) and Lazarus(IDE). Whether their assessment is better or worse than upstream's Lazarus Team's, I don't know.
What about one-single-window plugin, it is work-in-progress and it doesn't seems to me it is ready for production use, no matter would you get it as part of CT or download and add it to vanilla Lazarus. However maybe it better works on Linux than on Windows, I don't know.
There were however issues with code legality in CT grande bundle. It is widely believed that Orca (if I remember the name) violates copyrights of glScene/vgScene, which also happened in early Delphi FMX releases but was fixed by EMBA later. There also were disputes in FPC forums/wiki about CodeTyphon pirating some open-source components. See answer by Peter Dunne below.
Your question is akin to asking the difference between Linux and Ubuntu. Lazarus is an IDE/component library, based on FreePascal (FPC). And CodeTyphon is a distribution of Lazarus and FPC. So CodeTyphon is just one way to install a functioning installation of Lazarus.
Lazarus uses the same floating window design as older versions of Delphi. Installing from CodeTyphon won't change that.
Myself and several friends highlighted several licensing issues with codetyphon
most of which could have been corrected by sourcing the included files from known good source and ensuring the correct license headers were included
PirateLogic refused to correct the issues which means they are using code in direct violation of the original license terms
The fact its open source code does not change the fact they are pirating the code by not including the correct license even after the issue was highlighted
I also found several instances of copyright code included which appears to be proprietary and not FOSS at all
They also changed the path & file names on some libraries so that source is no longer compatible with standard lazarus/component installs
This in my view is totally illogical
These 2 factors heavily undermine what was potentially the best FPC/Lazarus distro
Hardly professional
Lazarus can be a daunting installation process due to it's nature as a cross compiling environment. You don't just download an installer and click ok. A typical "installation" is actually a bootstrap FPC compiler doing a three-pass compilation of an "install". There are plenty of good installation scripts/methods from the official Lazarus/FPC team and in the community for a . But, understandably, the installation process is a skill in itself.
CodeTyphon is a a different/separate branch of an installer system, which is more of a utility suite/tools/third party code compilation library. If you want the simplest installation experience go with CodeTyphon. It has the nice graphical front end for managing the compiler. You can conveniently do the fancy stuff like build "cross-compilers" for almost every "target" operating system out there. It also is jam packed with hundreds of the best components/libraries pre-installed. It is a very actively maintained project and very professional. A whole lot of work is done for you.
Even if you want to be learn the low level compiler capabilities, CodeTyphon is a good place to start. It is written in FCP/Lazarus and is open source. Simply study it as "working demo app" and the other info on the compiler details. If you crash it, at least you don't have to learn to climb the hill. You get to get to start from the top and lose control on the way down. Start from scratch (and a three hour reinstallation) Hahaha
Lazarus also has a package "AnchorDock" which allows you to dock all the windows into one. Either install the anchor dock design package after installing Lazarus, or install Lazarus using the script at getlazarus.org which will do it for you.

Using WebKitGTK+ on Centos 5.8?

I'm trying to build an embedded simple web browser for an embedded device and I've decided to use WebKit / WebKitGTK+. However, our device uses a Linux environment somewhat based on CentOS 5.8. I haven't been able to find any RPMS or mention of support for WebKit / WebKitGTK+ for CentOS 5.8 while doing several web searches.
Does anybody know if it's possible to build an older version of WebKitGTK+ such as 1.2.6-2.el6_0 which works well on CentOS 6.3? Are any RPMS available for CentOS 5.8?
The goal here is to be able to run a relatively current, at least 1.2.6 version of WebKitGTk on CentOS 5.8
Note: I was able to sort everything out. Just took a long time compiling all of the dependencies in the correct order with the correct options. I was able to get WebKitGTK 1.6.0 running on Centos 5.8.
You shouldn't have any problems building an old version of webkit if you can install the older versions of libraries that it requires.
If you have older or newer versions of GTK+ etc installed than the old version of webkit requires it may need quite a bit of porting to compile.
I'm not aware of any RPMs that meet your requirements
Depending on the compilation options you should be able to compile the dependencies in an isolated directory. With each library you typically use the --prefix option to specify the destination. Then when compiling something that depends on that library, you typically have an option to specify where to look for that library - something like --with-libraryname=/path/to/library. You want to check ./configure --help of each thing you're compiling to get the correct options.
It'll be quite a bit of work, but you should be able to compile everything you need into an isolated directory without replacing anything on the system. I would highly recommend you avoid doing this in root to ensure you have the right options.

DbLinq and Mono 2.4: Working Together?

Hopefully this is a silly question and there's really a simple solution somewhere out there but...
Has anybody successfully gotten DbLinq to play nicely with Mono 2.4 on Mac OS X 10.5?
I've got my SQLite database ready but for the life of me, I can't find sqlmetal to generate my objects.
I'm guessing I might have to download a previous version of Mono that included sqlmetal, build and install it, and then just use the code generated from that version on Mono 2.4...but I'm hoping to avoid it at all costs.
I'd avoid using DBLinq for production code... many of Linq-To-SQL's features aren't implemented, and walking through the source code shows a low level of maturity... many of the methods are not implemented or marked as "unterminated".
...you've been warned!
Using the pre-compiled binary in this case just doesn't work.
To get a properly generated DbLinq data layer, you have to use the sqlmetal tool included with Mono (but, apparently, not with the pre-compiled binaries for OS X). You have to pull down the Mono trunk (along with all the dependencies) and build Mono from the source.
Once you build and install Mono from source, you should have the sqlmetal tool. Once you generate your code, it's as easy as including the generated *.cs file and importing Mono.Data.Sqlite.
Mono 2.6 will include for the first time a preview of DbLinq with Mono. You can take it out for a spin today if you install DbLinq on your own side-by-side with your current Mono setup.