SonATA Porting

From setiquest wiki

Jump to: navigation, search

Contents

Description

The project is the result of 20 years of development by many different programmers. Until recently there has never been an effort to make the software available to developers outside of the SETI organization. Now all that has changed. We have spent the last year cleaning up the code and addressing licensing issues. The first release of the setiQuest SonATA project was March 1st, 2011 on GitHub.[1]

Now that the source code is available to the public we need to make a few improvements to help it become easier to use and understand, thus opening the door to more people becoming involved in the project.

The project will involve the following:

  1. Become familiar with downloading, building and running the SonATA software.
  2. Create a list of the most popular Linux distributions that SonATA should be ported to. Include Mac OS X, Solaris, BSD, and if you think it is possible, Windows.
  3. Attempt to download, build and run the SonATA software on other Linux distributions.
  4. Document and fix and issues that make SonATA not run on any of the Linux distributions.
  5. Interact with SonATA programmers to fix any issues that involve code changes.
  6. Improve the installation procedures so the download, build, and install instructions are the same for all Linux distributions.
  7. Create a detailed report on the project and how the SonATA source code was improved. We would like to release this information as an open source project improvement case study.
  8. Improve the install instructions and procedures. We currently have a number of software packages that need to be installed before the software can be downloaded, built, and run. The instructions we have are cumbersome at best and need to be refined.
  9. Building the software is a bit complicated and prone to developer error. We would like an all comprehensive configure or cmake build system to be implemented to make this easier. We are also willing to entertain using ant.
  10. Improve the demos that are run by the developer once the software is built.
  11. Improve the structure of the documentation. Not all the software has the necessary Doxygen headers. The Doxygen template needs improvement.
  12. Create a detailed report on the project and how the SonATA source code was improved. We would like to release this information as an open source project improvement case study.

This project is GSoC funded[2]. This project is a combination of 2 projects. The original project descriptions are at:

Members

Protocols

Milestones

This section outlines the general plan of the project. The mentor should add a list of project milestones here. When a milestone is reached a (date) should be added and the milestone stricken out.

At the end of each milestone we should have the equivalent of a "release". The changes will be checked in to GitHub.com and we should get several people to verify that they can build SonATA and benefit from the improvements.

First milestone

We will first concentrate on improving the current OpenSUSE build and demos system. Then move on to other OS's in future milestones.

Please help me refine this list.Jrseti 09:46, 18 May 2011 (PDT)

  1. Create a meta-package that depends upon all the extra packages necessary for operation.
  2. improve the build procedure to check for necessary installed packages.
  3. Can we make the configure script warn if there is not enough CPUs or RAM?
  4. Create one make procedure that builds everything. Including CppUnit, tclreadline, sse-pkg and sig-pkg.
  5. Modify the build instructions.
  6. Improve the build instructions. Can it be made easier?

At the end of this milestone the SonATA download and build procedure should be as easy as possible and not fail for others.

Second milestone

  1. Can we make it run with only 2GB memory? Investigate.
  2. Improve the demo/verification that SonATA is working (voyager demo).

Milestone n

GSoC calendar

Initial Tasks

Ported distribution versions

SonATA has been successfully ported to and tested on the following Linux distribution versions:[3]

Discussion

Which Linux distributions should we target?

I found this interesting chart:

LinuxDistros.png

From this, I think the list should be in order;

  1. SuSE
  2. Fedora
  3. Ubuntu
  4. Centos
  5. Debian
  6. Red Hat
  7. Gentoo

I included SUSE for completeness. Fedora is second because I believe KHRM already did a lot of work with this during the GSoC application period. Ubuntu is becoming popular and we have started using it here for other projects, so that is 3rd. Jrseti 09:48, 12 May 2011 (PDT)

How are we going to improve the build system?

Currently there are several problems with the build system that we need to improve. Review the build instructions for reference [[2]].

Discussion at [3] is arriving at these conclusions:

How are we going to improve the software?

Here are a few issues I see with the current software. These are up for discussion Jrseti 07:31, 17 May 2011 (PDT)

Documentation

Build System of SonATA:

User's perspective:

A user have to undertake the following steps to build the SonATA:

i) Running the sonata_i.sh script ./gsoc/sonata_i.sh

ii) Running autotools using the script autogen.sh ./autogen.sh

iii) A user have to run the configure to generate Makefile: ./configure --with-tcl=/usr/lib64 -C

iv) A user have to build using make: make

Options:
a) -jNo where No is the number of jobs. You can put twice the number of cores to build efficiently and quickly.
b) V=1 or V=0 verbose level . V=0 codes are builds much like in cmake.

v) Installing the SonATA:
sudo make install
sudo chown -R `whoami` ~/sonata_install

Package Maintainer Perspective:

SonATA consist SSE and Signal Processing code. Each having their own directories. There are also some other directories like scripts. And some other directories containing third party software needed to run SonATA.

Sonata.png

They all have configure.ac and Makefile.am files. These files generate the configure and Makefile.in. It must be noted these directories are not just sub-directories but sub-directories with nested packages. Also sig-pkg has another optional deep nesting . In these sub- directories under sig-pkg are treated as a nested packages . Further, its sub-directory utilities treat its sub directories as nested packages. By default, this feature is disabled.

To enable it give –enable-deepnesting option while configuring.

This feature is quite useful for a maintainer. If a nested package has been changed only. Then he can distribute that only by make dist after he has configured and build it.

Other useful feature is VPATH builds (Parallel builds or objdir builds). Build directory and source directory can be different. A user can start building in another directory he has created ( let's say build). But this feature cannot be used on nested packages as they depend on other packages sometime. This can be only used from top directory.

e.g.

cd ~/SonATA
mkdir build
cd build
../configure
make (options)
sudo make install
sudo chown -R `whoami` ~/sonata_install

Developer's Perspective:

This describes some of the details of internal and external parts of the build system:

Metapackages and sonata_i.sh script:

i) sonata_i.sh: This interactive script automates generating of script installing dependencies using meta packages, generating keys , downloading the SonATA if need be and other components and changing the files.

ii) rpm.spec: This is used to generate the meta package rpm.

Autotools:

Following changes have been brought into the build system:

VPATH BUILDS implementation:

By default vpath builds are enabled in autotools but if care is not taken while writing automake files they can easily break. So following changes had to be made and should be taken care whenever a new files are written:

1) Equating top_sourcedir variable to ..

While on a glance this seems to be correct and buildsystem will works but when VPATH build is tried it will break. Reason being top_sourcedir is not equal to .. in VPATH. To solve this just remove the reference to that. Value of this variable is taken care by configure . Same is the case with top_builddir.

2) Path to header files and library:

Currently there are two method for this. e.g. 

SSE_DX_INTERFACE_DIR = $(top_builddir)/../../../sse-pkg/sseDxInterfaceLib 
SSE_DX_INTERFACE_INCDIR = $(top_srcdir)/../../../sse-pkg/sseDxInterfaceLib 
SSE_DX_INTERFACE_LIBDIR = $(SSE_DX_INTERFACE_DIR) 
SSE_DX_INTERFACE_LIB = $(SSE_DX_INTERFACE_LIBDIR)/libsseDxInterface.a

Second is: 

GAUSS_DIR = $(top_srcdir)/../../gaussLib 
GAUSS_INCDIR = $(GAUSS_DIR)/include 
GAUSS_LIBDIR = $(GAUSS_DIR)/src 
GAUSS_LIB = $(GAUSS_LIBDIR)/libGauss.a

In first library's path is correctly given as top_builddir but in second it is wrong even though it will work when top_srcdir is equal to top_builddir as is the case in non VPATH builds.

I changed the all the reference to include and library’s like this.

Also where swig is used like in sse-pkg ifc and sse-pkg tsig, we will have to give path to file being used.

Like in case of tsig, we changed it from: 

swig -c++ -tcl -o TestSig_wrap.cpp -ltclsh.i TestSig.i

to: 

swig -c++ -tcl -o TestSig_wrap.cpp -ltclsh.i @srcdir@/TestSig.i
Control Over Nesting

Even then I later out found former approach to deal with library and header files to be slightly wrong in case of SonATA. As it assumes that top_sourcedir with respect to package is always at fixed distance. It will not be the case if we go for two configure files based build system as is the case when we go for nesting controls. One sig-pkg and another its own. Earlier there was no such issue as package's configure was used for generating it. So to correct the above two I wrote them as: 

SSE_INTERFACE_DIR = $(builddir)/../../../../sse-pkg/sseInterfaceLib 
SSE_INTERFACE_INCDIR = $(srcdir)/../../../../sse-pkg/sseInterfaceLib 
SSE_INTERFACE_LIBDIR = $(SSE_INTERFACE_DIR)
SSE_INTERFACE_LIB = $(SSE_INTERFACE_DIR)/libsseInterface.a

and 

GAUSS_DIR = $(srcdir)/../../../gaussLib 
GAUSS_INCDIR = $(GAUSS_DIR)/include 
GAUSS_LIBDIR = $(builddir)/../../../gaussLib/src 
GAUSS_LIB = $(GAUSS_LIBDIR)/libGauss.a

Now it works after I changed the configure file to give a choice over nesting of packages. By default it will be disabled.

Some other minor changes:

See also

References

  1. ↑ http://setiquest.org/forum/topic/open-sonata-source-code-released
  2. ↑ http://www.google-melange.com/gsoc/project/google/gsoc2011/khrm/21001
  3. ↑ http://irc.sigblips.com/setiQuest/2011/setiquest.07-26-2011.log

Documentation

External links

Retrieved from "http://setiquest.org/wiki/index.php/SonATA_Porting"
Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox