FYI: sqlite is going to be allowed in the future versions - the PR was
accepted and this library should be available for linking in future. Thank
you all who made it happen!
Rinigus
On Mon, Mar 6, 2017 at 1:18 PM, rinigus <rinigus....@gmail.com> wrote:
> 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
