[Kstars-devel] GSoC update and minor source tree layout organization changes

[Henry de Valence]

Hi all,

I posted an update [1] on the project on the blog a few days ago,
after I sorted out a clean way to make OpenCL an optional dependency
at both run- and compile-time. (Only one set of #ifdefs in one file!)

The OpenCL performance is pretty disappointing so far when compared to
the CPU, but I'm not going to bother looking into why this is at this
stage. (It has nothing to do with transferring data to the GPU or
something like that, though). Instead, I'm going to go on to the
second half of the project, restructuring the sky components to use
newer algorithms. The details of how the data is stored and processed
(see [1]) are totally hidden, so we can change that part later, and
optimize it for the case we care about (the skymap) and not the one we
don't care about (processing a million skypoints in a row). Once
that's done we can worry about performance issues.

On a related note, as I do things I've been trying to modularize and
clean some code. To this end, I've carried out some modest
reorganization, with the roughly the resulting structure:

kstars/
    - misc global project files
    src/
        ksengine/
            - all the new fast algorithms are here; doesn't use
anything GUI-related
        htmesh/
        datahandlers/
        kstars/
            - formerly kstars/kstars/
    data/
        icons/
        - data files like orbital elements, etc., formerly kstars/kstars/data
    tests/
        engine/
            - unit tests for the new algorithms
        parsers/
            - unit tests for some parser classes

The idea is to have all the source files in one tree and all the data
files in another tree, with the sources grouped into independent
modules.

Ideally, src/kstars/ would have just sources for KStars the GUI app
and everything else would be seperated, but this takes more work, so
I've put it off for now. It would be good if all of the
fitsviewer/indi/ekos/etc stuff in kstars/ was pulled out into seperate
static libraries, and even better if we could seperate the tools from
the main app. I think that this is a good start for modularization. If
we can cut down on the crazy amount of cross-#include-ing everything
from everywhere, it also means that compile times go down, which is a
plus.

These commits depend on my branch, though, so they're not in master
and won't be until I merge into master.

Cheers,
Henry

[1]: http://www.hdevalence.ca/blog/2013-07-28-kstars-gsoc-opencl-and-a-first-performance-report