[rasterlite2] build with CMake

[Miura Hiroshi]

Hi,

I'd like to use  spatialite and rasterlite2 library in WIndows thru vcpkg project.

https://github.com/Microsoft/vcpkg

A vcpkg project heavily utilize CMake build system.

There are spatialite package there, but not rasterlite.

Now I've tried to add CMake script to rasterlite2.

I'd like to propose add CMake build system in rasterlite2, cloud you give me a feedback for it?

You can find patches in github.

for trunk

https://github.com/miurahr/librasterlite2/commits/cmake

for librasterlite2-1.0.0-devel.tar.gz distribution

https://github.com/miurahr/librasterlite2/commits/cmake-1.0.0-rc0-devel1

It is successful to  build  and test on librasterlite2-1.0.0-devel.tar.gz distribution on Linux.

Hiroshi Miura

OSM Foundation Japan

[a.fu...@lqt.it]

On Tue, 20 Feb 2018 04:01:53 -0800 (PST), Miura Hiroshi wrote:
> Hi,
>
> I'd like to use  spatialite and rasterlite2 library in WIndows thru
> vcpkg project.
> https://github.com/Microsoft/vcpkg
>

Hi Miura,

"vcpkg" seems to be a rather interesting initiative coming
directly from Microsoft and intended to facilitate and
promote the usage of open source packages on Windows.
it surely is a good new if we consider that this marks
a complete inversion in the most traditional Microsoft's
attitudes about free/libre software; better late than never.

technically speaking, "vcpkg" doesn't introduces any really
innovative approach, and seems to be strongly inspired by
similar packaging systems already available on Mac OS X
since many years (MacPorts [1] and Homebrew [2])

[1] https://www.macports.org/
[2] https://brew.sh/

The basic concept inspiring all these package managers
is that they doesn't distribute binary executables; they
distribute instead sources and fully automated build
scripts.
such a design choice leaves the full burden of actual
compilation on the shoulders of the end user (and this
usually is an intensively time consuming task).

About five years ago I personally tested during a short
period Homebrew on Mac; it offered a very rich collection
of FLOSS libraries and applications and it was impressively
robust and effective.
Nonetheless I found it intolerably slow; updating the system
required a very long time, and was a real pain to the ass.

I read from the documentation that "vcpkg" can support the
distribution of binary packages as well (via the "export"
option), but I have no real idea about its practical
effectiveness.

> A vcpkg project heavily utilize CMake build system.
>

this is a very disturbing requirement; the vast majority
on FLOSS packages support build scripts based on the
canonical "automake".
and just to say, both MacPort and Homebrew can directly
support packages based on canonical "automake"; CMake is
an optional alternative (as in many Linux distros) and
not a strict platform requirement.

> There are spatialite package there, but not rasterlite.
> Now I've tried to add CMake script to rasterlite2.
>
> I'd like to propose add CMake build system in rasterlite2
>

just few quick considerations:

1. abandoning "automake" and fully switching to CMake
definitely is out of discussion, simply because it's
a rather drastic technology change that will offer
no real advantages.
"automake" nicely works on Linux, Mac OS X and
Android (and on Windows too, using MSYS and MinGW).
CMake on its own has just a single strength point:
it can effectively support Microsoft C++ as well.

2. supporting both "automake" _AND_ CMake seems to be
a much more interesting option, if it wouldn't
introduce any further complexity in the overall
maintenance of the project.

3. conclusion: I'll be absolutely glad to incorporate
directly into the sources of both libspatialite and
librasterelite2 any external contribution intended
to support CMake.
But this surely implies a strong commitment from the
contributor so to ensure that he/she will continue
to promptly update the CMake scripts in future years
and for future versions.
"drop and forget" contributions are poisoned gifts,
because they simply end up by making harder and
even more complex the maintenance of the project;
on the other hand long term contributions are always
welcome.


> could you give me a feedback for it?
>

I notice that you've based your CMake proposal on
librasterlite2-1.0.0-devel.tar.gz
Please note: this is a very old and nowadays completely
outdated codebase (July 2014); the current development
sources available from the Fossil repository have
certainly evolved a lot since then.
If you really want to do something useful you should
always keep in sync with the Fossil repo.

Note: the definitive stable asset of librasterlite2
is not yet available, and it's very probable that
more sources, features and so on will be added before
reaching the final milestone of some Release
Candidate. I suggest you to postpone for a little
while the development of your CMake script, waiting
for a more stable configuration that will surely
emerge in the next future.

bye Sandro