Hi Martin
Did you consider this recommendation?
>
> "To simplify matters, SQLite is also available as a pre-packaged
> amalgamation source code file: sqlite3.c. The amalgamation is a single file
> of ANSI-C code that implements the entire SQLite library. The amalgamation
> is much easier to deal with. Everything is contained within a single code
> file, so it is easy to drop into the source tree of a larger C or C++
> program. [...] *For these reasons, the amalgamation source file
> ("sqlite3.c") is recommended for all applications*."[1]
>
> What are the reasons that prevent you from using the upstream recommended
> approach? Are they worth your time and effort?
>
That's exactly what I am doing right now and have a linked sqlite3.c as
an amalgamation source file in the project. Project in question is an
offline maps server and it has been distributed via OpenRepos and Harbour
already with sqlite bundled into application. In that sense, I haven't
wasted much time on it, with the following exceptions:
* had to figure out that sqlite is banned
* had to add sqlite.c into the application
* treat SFOS build differently from normal Linux distributions (the server
supports Linux in addition to SFOS)
I would like not to waste my time by following SQLite releases and keeping
up with the bugfixes. For that, it would be better to use system-provided
library. Hence the request.
> Thinking out loud: If an application (in its packaged form) is to be
> supported on a variety of devices and (future) OS releases all its
> dependencies must be satisfied in these environments. In order to make both
> the OS/devices vendors' and app developers' life easier in this respect a
> minimal *necessary* subset of all the APIs provided by the OS (at
> particular time) is defined that is guaranteed to be universally available
> in some time frame. Feel free (encouraged!) to use any other dependencies,
> even those completely missing in the OS (yet), bundling these together with
> your application! Only where this is not possible and/or implies an
> excessive effort and/or adds dozens of megabytes etc. it is worth to wait
> for Harbour rules to change.
>
In essence, it boils down to the difference in approaches: either we have
a distribution of libraries that developers can rely upon (debian, fedora,
gentoo) or we have a host with almost no support for development and each
app ensures its environment by itself (virtual machine, chroot, new fancy
packaging proposed by ubuntu or others?). The problem is that the packaging
tools used on SFOS are developed for the first approach. I am expected to
just specify in RPM spec my dependencies and all should be fine. If we
stick to package-all-you-need-in-an-app, then its probably better to have
tools developed for it.
There is of course the third way - roll out a distribution on the top of
SFOS. So, skipping Harbour and establishing an alternative approach that is
in line with the common Linux practice and allows developers to use Linux
tools to their full potential and focus on developing. As far as I can see,
it would need a decent GUI, policy agreement and enforcement, and could be
rolled out through OBS or dedicated OpenRepos channel. I probably forget
many details, but it should be possible. The more I hear about difficulties
with different Qt modules (QtLocation) the more I am inclined towards it.
But as usual, lack of time and other priorities take a preference. So,
don't take this too seriously.
In my case, the application has so many dependencies covering many aspects
of maps functionality that adding sqlite is not too bad. With the exception
of keeping track on sqlite bug fixes that I can predict I will forget to do
in any decent time interval. Which is a shame since someone @Jolla is doing
it.
Best wishes,
Rinigus
_______________________________________________
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
