On May 24, Dan Kennedy wrote:
On 05/24/2012 10:53 PM, Larry Brasfield wrote:
>> On the support page http://www.sqlite.org/howtocompile.html, it says:
>>
>> "The use of the amalgamation is recommended for all applications."
>>
>> Is this a general recommendation, to use the amalgamated source file
>> as the preferred way of including SQLite functionality in one's
>> application, rather than using a separately compiled library?
>>
>> Or should I read this as a recommendation just in case I need to
>> compile SQLite from source, and need to decide between using the
>> amalgamation or using the individual source files?
>
> From the context of the recommendation, one can clearly infer that it
> addresses only how SQLite source is presented to the compiler. Whether
> the compiler's output is embedded in its own object file, a DLL, or
> directly into a calling program is not addressed.
>
The statement above is accurate.
But at the same time, it is a general recommendation that
you just pull sqlite3.c into your project instead of messing
around with shared libraries and so on.
Why risk ending up with an unexpected (possibly old) version
by linking at runtime just to save users less than 300K of disk
space?
I don't want to quibble about language here, but I see nothing at the
quoted link about whether sqlite3.c should be used as a shared library,
(or a static library).
For most projects, I expect that the recommendation you suggest makes
sense. However, the OP has indicated little that would allow us to
guess whether his project should follow the norm or not. There may well
be issues other than disk space at stake. For example, the .NET
adaptation of SQLite benefits from being a shared library as this fits
well into the "black box with well defined interface" usage model the
.NET developers routinely use with a variety of packages.
Best regards,
--
Larry Brasfield
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
