On Wed, Feb 18, 2009 at 5:30 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> On Wed, Feb 18, 2009 at 8:42 AM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
>> On Thu, Jan 29, 2009 at 7:19 AM, Paul Burba <ptburba_at_gmail.com> wrote:
>>> Right now when building trunk on Windows you have one option when it
>>> comes to sqlite: Use the --with-sqlite option to gen-make.py to point
>>> to a directory with this structure and contents:
>>>
>>> inc/
>>> inc/sqlite3.h
>>> lib/
>>> lib/sqlite3.lib
>>>
>>> So basically, if you haven't built sqlite on your own already then
>>> Subversion won't build. It seems to me we should support sqlite build
>>> options analogous to those on *nix, e.g. just drop the amalgamation
>>> files in .\sqlite-amalgamation and it gets built.
>>>
>> Hi Paul,
>>
>> Thanks for noting that. I've looked to current sqlite build stuff on
>> Windows. It still does not support sqlite-amalgamation.
>>
>> So I propose to implement only amalgamation option for sqlite, without
>> supporting to use "installed" version of library. Since there is no
>> term of installed libraries on Windows. I do not see benefits of using
>> sqlite compiled out of source tree on Windows. It can be only source
>> of problems if different compiler or compiler options will be used.
>>
>> I volunteer to implement support for sqlite amalgamation on Windows,
>> if no one object to drop other sqlite build option on Windows.
>
> +1
>
> I'd ask that you make it work with the format of the way it is shipped
> in our deps zip file, assuming we are not going to include it in the
> source tree.
Ok, I take account of this.
>
> Personally, I'd also like to see it statically linked in
> libsvn_subr-1.dll and not an external DLL as well. If we are going to
> build it, then let's not make it possible to load the wrong DLL at
> runtime too.
Sure, I'll make it in the same as we do with serf and zlib. There
statically linked to our libraries.
--
Ivan Zhakov
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1186458
Received on 2009-02-18 16:02:29 CET