Changing my Operating system (part 2)

This is a follow-up post on changing my OS to OpenBSD.  There I explained how I used to go back and forth between different BSDs. I was also pulling myself out of changing to another OS.  After passing almost an year, I decided to stay with this OS. I didn’t have to regret once for replacing GNU/Linux with OpenBSD. Sure it give me hard time when dealing with some projects. Sometimes, I become first one who build project X on OpenBSD.  ChezScheme and HPX5 come to mind!

Sometimes a particular feature is not available in OpenBSD or it is not doing things the way; how the rest of the world is doing. Greping through openbsd mailinglist always gives a reasonable explanation and I found it okay to live without such features.

It is lot of fun having this as my choice of Operating system for development and home and I keep learning a lot from its code and how development is moving on. In future, I hope to become a developer for this project.

Thanks to all OpenBSD developers..

Donate to OpenBSD project:



Libkml and CMake’s ExternalProject

A while ago, I added ExternalProject support for easy building libkml library.  Initially I stepped into add CMake build and later added ExternalProject  calls. To be frank, at the time of adding cmake support to libkml, there was an ongoing discussion with Dimitry of gdal-dev and he have the idea of cmake-ification of gdal. It seems interesting because of numerous optional and mandatory libraries GDAL has to deal with in a build.

So after some private mail exchanges, I did some modification to libkml cmake to download, build, install libraries and then build libkml. It was also the time, I did a revamping on OTB’s SuperBuild[¹] and it revealed a lot about the traps and horrors of using ExternalProject.

Like any other feature in any project, this CMake feature has some ups and down and so far, it seems more of traps using it in projects.  I had to revert back (not a git revert) ExternalProject changes in libkml project. One thing I found was monopoly of cmake using this feature. One has to add cmake build for other project just to play well with ExternalProject in libkml. In my case, I had to add uripaser, minizip and Boost. There is no guarantee that upstream developers are willing to accept this changes.  So maintenance in tedious. At least, this is well known fact from OTB. [2][3][4]

“You are not adding a build system, you are making a private and rather buggy version of package management tool”

[1] SuperBuild: This is same code using ExternalProject but it is called SuperBuild in ITK and therefore in OTB.




CMake build system for GRASS GIS

This is a series of blog about my ongoing development on GRASS GIS. Readers are not expected to have an expertise in GRASS GIS but having some knowledge of building and compiling projects with AutoConf , AutoMake is expected. This particular feature is about enhancing grass build sytstem by adding CMake

After writing enough amount of CMake scripts for various projects in and out of work hours, I decided to add CMake support to GRASS GIS. Well, initially I thought to work on GDAL but the project has different ideas on adding cmake build many of  which I don’t completely agree. This work not related to my paid job and I am allowed to work on certain projects without going through a CLA from my company. AutoMake support currently in GRASS is very good and stable on UNIX and UNIX-Like platforms and it comes after years of testing and development. For cross-platform build scripts nothing so far beats CMake!. Imagine you can get native Visual Studio support using CMake build. By support I mean developers will be able to setup  VS IDE project or XCode project on OSX!.

For starter, I tried to build grass_gis module with cmake. It seemed very easy. Well, at first look they all do right? That is how you get sucked into it spending weekend inside your appartment with subway sandwiches and little or no sleep.!!

It seems grass_gis depends on another module grass_datetime.  And datetime module was fairly easy to build. just a couple of C source files and done.

source code is organized in grass with each library/application in its own directory which was grouped under a module. I wish I could give some cool screenshots and explain this to you. But I don’t want to!. Because it was boooring… especially if I start this blog with “expected no experience in grass gis”. Many of GRASS users are not aware of how or why source is organized this way and they really don’t want to.

So a CMakeLists.txt is added to each directory and some of them only have a call to add_subdirectory().

Although I started with grass_gis module but then moved to grass_datetime module. This is to because datetime module has zero external dependencies and all I have to write is a basic hello-cmake-tutorial amount of code.

I have to face external libraries (finding, include, linking) one day but today is not that day.  Even though the cmake code seems minimum and it was lot of fun porting GNUMakefile to CMakeLists. Most of the code in include/Make are straighforward and easy to use without no expertise in AutoMake.  I guess this is enough for a start and now I can’t postpone it forever.  I would like thank all grass developers who are always helpful and hope users and developers will be able to build grass using CMake

Stay tuned.. Next part coming soon.

Changing my Operating system

Usually, I pick up with debian at work and home and sometimes think of dual booting my system with a BSD operating system.

So Which BSD should I use? There are many choices and each are different even if they share code for some projects. Each has a  unique philosophy, politics, technical team and a foundation. But tech team in all BSD is much better than any other Operating systems so far. I don’t want to step into BSD vs Linux distro vs Windows vs .. debate. So let’s come back.

I don’t have anyone at work using a BSD that I am aware of. Some of them even don’t know about BSD. Asking on any existing forum is not a right move unless, I can find a reply from me from future!. But I would be lying that I didn’t search around internet to know why each of them are special and in what way that attracts me.  You can find things like

FreeBSD is more general purpose. I use it for desktop and server.

NetBSD is more portable. If you had searched about NetBSD, it is highly likely that you might have read: “If I want a toaster I use NetBSD or I will use a FreeBSD”

OpenBSD is more secure and if you want a secure OS use OpenBSD. So everyone want a secure OS no matter what you work right?. And remember this is not just a matter of highly secure login. 3-stage password verification and stuff like that. OpenBSD is much more.

So this BSD wave comes and goes without sticking ever into my laptop at home or work.

After a long long time………

I installed FreeBSD with zfs. Installation was not unpleasant. But first boot after install, I got a boot error. This was with FreeBSD 10.0. Looking on freebsd bug tracker this was a known issue. “ZFS cannot work with intel core2duo cPu”. Well, that was pretty neat for a general purpose OS. I gave up and didn’t tried other BSD as I lost a lot of time reinstalling, checking installation media, looking on bug tracker. You know the error is in boot code.

Two months ago…

I tried FreeBSD 10.3-release and 11.0-current in that order and was amazed to see the same error. No fix yet. There was patch attached in bug report but nobody cared.

Three weeks ago..

I got a spare laptop with no OS. So BSD wave come back like a tsunami. But this time I was prepared to not touch a FreeBSD and focused on OpenBSD.

Installation was easy. Just a couple of questions. mostly yes, no, hostname.  X  was installed by default. wifi was detecting with no problem. I installed dwm windows manager, tabbed and configured xterm and started using OpenBSD in less that 10 mins after installation.

It was very good experience using OpenBSD and wonder why is it not popular like any other linux distro. There aren’t many packages in OpeBSD which is true. But I found everything I need to replicate my development environment on Debian. Having less packages, is not a kind of excuse for me who build most of my projects from source. It has everything required for a desktop or a server use. OpenBSD has very good code base with lot of non-optional security policies which I like. I very much appreciate the effort put by OpenBSD guys.  It is a wonderful and successful effort to make a good Operating system.

I will stay with OpenBSD for now.

Finally libkml 1.3.0!

After years of inactive development, fork updates, discussion, waiting around for answers, trying a lot of quirk fix. I am finally going to release libkml 1.3.0. I have to thank Mr. Bas Cowenberg for his support which made me to take it up to here. I also thank other projects using libkml that showed a willingness to test this fork.

What’s new in 1.3.0 ?
cmake build system
cleanup of embedded sources
charming ExternalProject that allows to download and build
Generated config files for easy use of libkml with other projects.