Tag Archives: open source

Preparing for Subversion to Git migration

Posted on by
5

GEOS is slowly moving to Git, so I decided to clear the Subversion specific settings, namely the svn:keywords. The procedure is quick and based on the commands I used to perform bulk svn:keywords property update.

First, svn:keywords property is removed:

find . -path '*/.svn' -prune -o -type f -print  | xargs svn propdel -q svn:keywords

Next, line consisting of $Id$ keyword is stripped from every plain text file using a tiny script coded in Python:


#! /usr/bin/env python
import fileinput
import re
import sys

def strip_line(filename, rx):
    sys.stderr.write(filename + '\n')
    for line in fileinput.input(filename, inplace=1):
        m = re.match(rx, line)
        if m is None:
            sys.stdout.write(line)
        else:
            sys.stderr.write(line)

if len(sys.argv) < 2:
    sys.exit("Missing filename")

pattern = '^.*\$Id.*$'
rx = re.compile(pattern, re.DOTALL)
strip_line(sys.argv[1], rx)

The script is executed for every file, excluding the working copy admin area in .svn:

for f in `find . -path '*/.svn' -prune -o -type f -print`; do ~/bin/strip_line_regex.py $f; done;

Voila!

Update: Torvalds answers Does GIT has vc keywords like CVS/Subversion?

Open Source, Decoupled and Accelerated

Posted on by
Reply

All right, I confess, I’ve lied a bit in the topic. I’m not going to discuss any of the Free and Open Source Software philosophies here. What I’m going to do is to smuggle an interesting discussion that I believe it may be interesting to other Open Source Software hackers, especially projects from the C/C++ camp of the OSGeo Foundation. I would also say that subject of this discussion is quite idiomatic to the universe of FOSS production. It is about a software project. A project that has grown and it has grown in many dimensions, also in parallel dimensions.

“See the turtle of enormous girth!
On his shell he holds the earth.” — Stephen King

Infrastructure supporting a project becomes insufficient, maintenance is difficult, release process is a full-time job and situation has taken a lot of the fun out of participating. Population of users and developers has grown. As the Community gathers appreciable portfolio of masters of the software development craft, it is in constant state of snowball war exchanging fire of ideas, new projects and discussions. It’s truly a pleasure to learn about them but, well, it pours oil on the fire of entropy. Here we come to the crux.

Gain of entropy eventually is nothing more nor less than loss of information — Gilbert N. Lewis

Today, David Abrahams posted, somewhat provocative, e-mail to the Boost project mailing list. It is titled Boost, Decoupled and Accelerated and delivers the following message: It’s time to make Boost development fun again.

It may sound like yet another internal discussion within an Open Source project. There are zillions of similar debates archived around. Yes, indeed, but not exactly. In fact, David announced something that may be of wider interested. It is

a system called Ryppl to decentralize development, testing, release, and installation of interdependent projects

followed by yet more interesting comment

I believe this project has the potential to change the face not only of Boost, but of open-source software in general.

One may think, well, it seems related to the issue of the current trends or we’re suffering redundancy in IT prophets. Perhaps, perhaps, perhaps… but what I know for sure is that David Abrahams is one of my favourite and highly regarded software developer and author. I can hardly recall any of David’s comments, observations or suggestions that would be lacking of point, I mean a very rational point.

I have licked a bit of experience myself of working with or maintaining complex projects or projects that feel complex. I think I wouldn’t risk anything saying David has a point. I’m looking forward learning more about the whole idea.

I hope I’ll be able to confirm it myself while listening to David’s presentation at BoostCon’10.

Quick CMake of GEOS

Posted on by
2

It’s an example of b***dy quick attempt to configure CMake-based build of a fairly large library written in C++ programming language. It is GEOS.

Seven. A lucky number. Arnulf‘s nickname. Total number of lines (commands) of CMake script to configure build of GEOS C++ core as a static library using sources form SVN trunk:

Create trunk/CMakeLists.txt file:

project(geos)
cmake_minimum_required(VERSION 2.6)
set(CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake")
add_subdirectory(src)

Create trunk/src/CMakeLists.txt file:

include_directories(${CMAKE_SOURCE_DIR}/include)
file(GLOB_RECURSE geos_SRC ${CMAKE_CURRENT_SOURCE_DIR}/*.cpp)
add_library(geos STATIC ${geos_SRC})

In fact, only six lines are really required. The third line in file trunk/CMakeLists.txt is optional.

mloskot@dog:~/dev/geos/_svn/trunk$ svn status
?       CMakeLists.txt
?       src/CMakeLists.txt
mloskot@dog:~/dev/geos/_svn/trunk$ mkdir ../build
mloskot@dog:~/dev/geos/_svn/trunk$ cd ../build/
mloskot@dog:~/dev/geos/_svn/build$ cmake ../trunk
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Configuring done
-- Generating done
-- Build files have been written to: /home/mloskot/dev/geos/_svn/build
mloskot@dog:~/dev/geos/_svn/build$
mloskot@dog:~/dev/geos/_svn/build$ make -j5
Scanning dependencies of target geos
[  0%] Building CXX object src/CMakeFiles/geos_lib.dir/operation/valid/RepeatedPointTester.cpp.o
...

and 53 seconds later my Intel Core 2 Duo 2.4GHz box announces:

[100%] Building CXX object src/CMakeFiles/geos.dir/linearref/LengthIndexOfPoint.cpp.o
Linking CXX static library libgeos.a
[100%] Built target geos

This build configuration is universal and cross platform, thus should work on all platforms supported by CMake.

Simply, you can not afford not use the best cross-platform build system that ever existed :-)

PostGIS 1.5.0 will require GEOS 3.1.0+

Posted on by
Reply

PostGIS spatial database extension for PostgreSQLPostGirls and PostBoys, be prepared!

The upcoming release of PostGIS 1.5.0 (available as beta1 beta2) will require GEOS in version 3.1.0 or later.

The beta1 testing results suggested to bump the minimum GEOS version to 3.1.0. The GEOS requirement issue was one of the heavily discussed topics on the postgis-devel this month.

The PostGIS team is going to give GEOS a nice present for its 10th round month birthday.

New GEOS source structure

Posted on by
2

Following quick announce a few days ago, I started shifting GEOS source code directories to flatten the structure a bit and to separate header files (.h) from implementation files (.cpp).

The whole process is documented as ticket #315 in the GEOS Trac. The transition has been remarkable smooth. The mission accomplished.

I’ve managed to build and successfully test GEOS with the following configurations:

  • GCC 4.4.1 on Ubuntu 9.10 64-bit with 64-bit build target
  • Visual C++ 8.0 on Windows XP Professional 32-bit with build target 32-bit
  • Visual C++ 9.0 on Windows Vista 64-bit (target 32-bit)
  • Visual C++ 10.0 on Windows 7 Professional 64-bit (target 32-bit)

All build configuration should work well. Let me know if any doesn’t.

The Myth of Objectivity

Posted on by
3

I do not advocate anything or anyone. All right, may be I do advocate but only a few small tiny things like C++ programming language, generic programming and high quality of software code and design and my dog, of course. However, I let myself to go down in the discussion about advantages and disadvantages of Open Source GIS on OGC forum at LinkedIn and somewhat at OSGeo mailing list too.

A human nature pisses me off, sometimes. (I am a human being, in case of doubt.) The world is bloody relative but we love to sling absolutes around. Yeah, we love this game! We are not good in learning from mistakes, anyway. Thus, the only achievement of attempting to apply a patch to someone’s buggy ignorance is a waste of time and may be a bit of training in fast typing or boxing ;-)

Paul is right recommending don’t feed the troll!. But, what has been learned is going to be lost, naturally.