You are not logged in.
Pages: 1
Hi Arnaud
in respect to http://synopse.info/fossil/info/b24c274049
I will have to move my sqlite3 DLL projects (dproj/groupproj) to a separate folder.
This is not a problem.
Thanks.
Offline
Hi Arnaud
I have been rethinking this a little and so I have a question regarding this: Did you modify sqlite3.c yourself to adapt it for mormot (static) linking? or is it an unchanged sqlite.c from another distribution?
From my point of view it would make sense to have one sqlite code base, so if you would 'wrap' your changes in #ifdef MORMOT_STATIC #endif compiler directives in sqlite3.c , it would still allow for "one" distribution of the sqlite sources, and thus also allow for the DLL projects code to be provided with the mormot project.
Offline
This is the official "amalgation" sqlite3.c file from http://sqlite.org but with two modifications:
- A custom header with some #define within;
- Both winread() and winwrite() methods have been changed into external.
The later is needed for our proprietary file encryption, which is much simplier than the "official" one, which need a lot of code change.
You should just use the the official "amalgation" sqlite3.c file from http://sqlite.org when building a .dll.
Or run c.bat to compile the sqlite3.obj.
We only put sqlite3.c in our source code repository for convenience and transparency, for building sqlite3.obj.
It is easier/faster to work like this.
It appears that the upcoming 3.7.17 version may use memory-mapped files, so won't work directly with our winread/winwrite functions hook.
So we may consider using something else.
Offline
Pages: 1