SQLite Provider issue

19 messages Options
Embed this post
Permalink
Helio Chissini de Castro

SQLite Provider issue

Reply Threaded More More options
Print post
Permalink
Hi guys

I met a issue now in SQLite provider port.

The current  code is already made with CMake, so to match all other providers
means that i need replace current build for the one i'm working.
I don't know how is the policy to do that, since this will  effectively replace
the only one working today.

So, can i go with replacement or there are any concern in this ?


[]'s

--
Helio Chissini de Castro
KDE Developer
Brasil/South America Primary Contact
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Traian Stanev

RE: SQLite Provider issue

Reply Threaded More More options
Print post
Permalink
Hi Helio,

You can replace the existing CMake files.

Thanks,
Traian


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Helio Chissini de Castro
Sent: Thursday, June 04, 2009 11:47 AM
To: [hidden email]
Subject: [fdo-internals] SQLite Provider issue

Hi guys

I met a issue now in SQLite provider port.

The current  code is already made with CMake, so to match all other providers
means that i need replace current build for the one i'm working.
I don't know how is the policy to do that, since this will  effectively replace
the only one working today.

So, can i go with replacement or there are any concern in this ?


[]'s

--
Helio Chissini de Castro
KDE Developer
Brasil/South America Primary Contact
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Helio Chissini de Castro

Re: SQLite Provider issue

Reply Threaded More More options
Print post
Permalink
Em Quinta-feira 04 de junho 2009, às 12:52:54, Traian Stanev escreveu:
> Hi Helio,
>
> You can replace the existing CMake files.
>
> Thanks,
> Traian
>

Traian, i have a few questions about SQLite providers:

- Is it tested on Linux ? Trying to compile SpatialIndex there's windows only
entries. ( HANDLE, explicit <windows.h> )

- Is really needed use a second sqlite copy in a subdir ? Because this lead us
to an not so good situation, since we have two different versions of sqlite in
the fdo code, the ThirdParty one and the one inserted in SQlite provider.

[]'s

--
Helio Chissini de Castro
KDE Developer
Brasil/South America Primary Contact
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Traian Stanev

RE: SQLite Provider issue

Reply Threaded More More options
Print post
Permalink

Hi Helio,

For Linux, you need to compile the SpatialIndex.cpp, rather than DiskSpatialIndex.cpp. They both have the same API, but only the first one compiles on Linux.

Traian


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Helio Chissini de Castro
Sent: Thursday, June 04, 2009 12:38 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] SQLite Provider issue

Em Quinta-feira 04 de junho 2009, às 12:52:54, Traian Stanev escreveu:
> Hi Helio,
>
> You can replace the existing CMake files.
>
> Thanks,
> Traian
>

Traian, i have a few questions about SQLite providers:

- Is it tested on Linux ? Trying to compile SpatialIndex there's windows only
entries. ( HANDLE, explicit <windows.h> )

- Is really needed use a second sqlite copy in a subdir ? Because this lead us
to an not so good situation, since we have two different versions of sqlite in
the fdo code, the ThirdParty one and the one inserted in SQlite provider.

[]'s

--
Helio Chissini de Castro
KDE Developer
Brasil/South America Primary Contact
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Badreddine Karoui

RE: SQLite Provider issue

Reply Threaded More More options
Print post
Permalink
In reply to this post by Helio Chissini de Castro
The thirdparty SQLite library is an older version needed by the SDF provider. The SDF provider needs the older version for binary compatibility reason since the latest version used by the SQLite provider is not backward compatible to the version used by the SDF provider.

Badreddine

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Helio Chissini de Castro
Sent: Thursday, June 04, 2009 12:38 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] SQLite Provider issue

Em Quinta-feira 04 de junho 2009, às 12:52:54, Traian Stanev escreveu:
> Hi Helio,
>
> You can replace the existing CMake files.
>
> Thanks,
> Traian
>

Traian, i have a few questions about SQLite providers:

- Is it tested on Linux ? Trying to compile SpatialIndex there's windows only
entries. ( HANDLE, explicit <windows.h> )

- Is really needed use a second sqlite copy in a subdir ? Because this lead us
to an not so good situation, since we have two different versions of sqlite in
the fdo code, the ThirdParty one and the one inserted in SQlite provider.

[]'s

--
Helio Chissini de Castro
KDE Developer
Brasil/South America Primary Contact
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Traian Stanev

RE: SQLite Provider issue

Reply Threaded More More options
Print post
Permalink

Oh, and also, the copy of SQLite in the SQLite provider subdir is also necessary, since it is a specially modified version of SQLite. You will not be able to compile the provider with a regular (obtained with apt-get for example) version of SQLite.

Traian


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Badreddine Karoui
Sent: Thursday, June 04, 2009 1:04 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] SQLite Provider issue

The thirdparty SQLite library is an older version needed by the SDF provider. The SDF provider needs the older version for binary compatibility reason since the latest version used by the SQLite provider is not backward compatible to the version used by the SDF provider.

Badreddine

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Helio Chissini de Castro
Sent: Thursday, June 04, 2009 12:38 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] SQLite Provider issue

Em Quinta-feira 04 de junho 2009, às 12:52:54, Traian Stanev escreveu:
> Hi Helio,
>
> You can replace the existing CMake files.
>
> Thanks,
> Traian
>

Traian, i have a few questions about SQLite providers:

- Is it tested on Linux ? Trying to compile SpatialIndex there's windows only entries. ( HANDLE, explicit <windows.h> )

- Is really needed use a second sqlite copy in a subdir ? Because this lead us to an not so good situation, since we have two different versions of sqlite in the fdo code, the ThirdParty one and the one inserted in SQlite provider.

[]'s

--
Helio Chissini de Castro
KDE Developer
Brasil/South America Primary Contact
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Jason Birch

RE: SQLite Provider issue

Reply Threaded More More options
Print post
Permalink
In reply to this post by Badreddine Karoui
By binary compatibility, do you mean that the compiled 3rd party dll wouldn't be readable by the SDF provider, or that generated SDF files wouldn't be readable by older SDF providers?

Would there be any way for 3.5 to standardise on a single (modified) SQLite library shared between both SDF and the SQLite provider?  That would at least get us down to one non-vanilla SQLite dependency.

Jason

-----Original Message-----
From: Badreddine Karoui
Sent: Thursday, June 04, 2009 10:04 AM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] SQLite Provider issue

The thirdparty SQLite library is an older version needed by the SDF provider. The SDF provider needs the older version for binary compatibility reason since the latest version used by the SQLite provider is not backward compatible to the version used by the SDF provider.

Badreddine

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Badreddine Karoui

RE: SQLite Provider issue

Reply Threaded More More options
Print post
Permalink
It's the file generated by the SDF provider that has the binary compatibility issue; the latest SQLite library will not be able to read the files created by the SDF provider.

The SQLite provider takes advantage of new features provided by the latest SQLite library and it would not be a good idea to base the provider on an older version.

Badreddine


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Jason Birch
Sent: Thursday, June 04, 2009 1:17 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] SQLite Provider issue

By binary compatibility, do you mean that the compiled 3rd party dll wouldn't be readable by the SDF provider, or that generated SDF files wouldn't be readable by older SDF providers?

Would there be any way for 3.5 to standardise on a single (modified) SQLite library shared between both SDF and the SQLite provider?  That would at least get us down to one non-vanilla SQLite dependency.

Jason

-----Original Message-----
From: Badreddine Karoui
Sent: Thursday, June 04, 2009 10:04 AM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] SQLite Provider issue

The thirdparty SQLite library is an older version needed by the SDF provider. The SDF provider needs the older version for binary compatibility reason since the latest version used by the SQLite provider is not backward compatible to the version used by the SDF provider.

Badreddine

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Helio Chissini de Castro

Re: SQLite Provider issue

Reply Threaded More More options
Print post
Permalink
In reply to this post by Jason Birch
Em Quinta-feira 04 de junho 2009, às 14:16:45, Jason Birch escreveu:
> By binary compatibility, do you mean that the compiled 3rd party dll
> wouldn't be readable by the SDF provider, or that generated SDF files
> wouldn't be readable by older SDF providers?
>
> Would there be any way for 3.5 to standardise on a single (modified) SQLite
> library shared between both SDF and the SQLite provider?  That would at
> least get us down to one non-vanilla SQLite dependency.
>
> Jason

As a quick look i did here, SQLiteInterface can be compiled using the modified
SQLite Provider included.
So would be ok if we push the Provider ones in ThirdParty, modify it to use a
different library name, for example SQLiteFDO and even install in system if we
decide to use shared.
This allows to always be sure we're using the FDO SQLite version. Is a thing
that mapguide can do in future release with their modified GD

[]'s

--
Helio Chissini de Castro
KDE Developer
Brasil/South America Primary Contact
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Jason Birch

RE: SQLite Provider issue

Reply Threaded More More options
Print post
Permalink
In reply to this post by Badreddine Karoui
So we're basically stuck with an old version of SQLite for the SDF format forever (or until we decide to rev SDF to version 4 or something)?

I agree that it wouldn't make sense to use an older version of SQLite for the SQLite provider.  My hope is that it will eventually read (though not optimally) other SQLite schemas such as SpatiaLite or just X/Y columns, and using an old version would constrain this potential.

Jason

-----Original Message-----
From: Badreddine Karoui
Sent: Thursday, June 04, 2009 10:24 AM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] SQLite Provider issue

It's the file generated by the SDF provider that has the binary compatibility issue; the latest SQLite library will not be able to read the files created by the SDF provider.

The SQLite provider takes advantage of new features provided by the latest SQLite library and it would not be a good idea to base the provider on an older version.

Badreddine

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Jason Birch

RE: SQLite Provider issue

Reply Threaded More More options
Print post
Permalink
In reply to this post by Helio Chissini de Castro
Helio Chissini de Castro wrote:
> So would be ok if we push the Provider ones in ThirdParty, modify
> it to use a different library name, for example SQLiteFDO and even
> install in system if we decide to use shared.

So, since it looks like both the SDF provider and the SQLite provider require modified versions of SQLite, we would have two renamed libraries: SQLiteFDO and SQLiteSDF?

I do like the idea of shared libraries in general, but in this case I'm not sure that it makes sense to pollute the system with these single-use-specific items.

Jason

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Helio Chissini de Castro

Re: SQLite Provider issue

Reply Threaded More More options
Print post
Permalink
Em Quinta-feira 04 de junho 2009, às 14:36:26, Jason Birch escreveu:

> Helio Chissini de Castro wrote:
> > So would be ok if we push the Provider ones in ThirdParty, modify
> > it to use a different library name, for example SQLiteFDO and even
> > install in system if we decide to use shared.
>
> So, since it looks like both the SDF provider and the SQLite provider
> require modified versions of SQLite, we would have two renamed libraries:
> SQLiteFDO and SQLiteSDF?
>
> I do like the idea of shared libraries in general, but in this case I'm not
> sure that it makes sense to pollute the system with these
> single-use-specific items.
>
> Jason

No, the SDF provider need only etilities/sqliteInterface, and SQLiteInterface
can use the new version of SQLite
The only thing about utilities/sqliteinterface is that code includes on
private header ( btree.h ), which the new version have as well.
So we can use the newest version, even modified, for whole fdo.

--
Helio Chissini de Castro
KDE Developer
Brasil/South America Primary Contact
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Badreddine Karoui

RE: SQLite Provider issue

Reply Threaded More More options
Print post
Permalink
In reply to this post by Jason Birch
As far as the SDF goes, the version of SQLite is not relevant since it's a low level implementation details. In another word, the SDF file is not an SQLite file. I don't think we should move the SDF provider to another version of SQLite.

Badreddine


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Jason Birch
Sent: Thursday, June 04, 2009 1:32 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] SQLite Provider issue

So we're basically stuck with an old version of SQLite for the SDF format forever (or until we decide to rev SDF to version 4 or something)?

I agree that it wouldn't make sense to use an older version of SQLite for the SQLite provider.  My hope is that it will eventually read (though not optimally) other SQLite schemas such as SpatiaLite or just X/Y columns, and using an old version would constrain this potential.

Jason

-----Original Message-----
From: Badreddine Karoui
Sent: Thursday, June 04, 2009 10:24 AM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] SQLite Provider issue

It's the file generated by the SDF provider that has the binary compatibility issue; the latest SQLite library will not be able to read the files created by the SDF provider.

The SQLite provider takes advantage of new features provided by the latest SQLite library and it would not be a good idea to base the provider on an older version.

Badreddine

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Helio Chissini de Castro

Re: SQLite Provider issue

Reply Threaded More More options
Print post
Permalink
In reply to this post by Traian Stanev
Em Quinta-feira 04 de junho 2009, às 13:39:50, Traian Stanev escreveu:
> Hi Helio,
>
> For Linux, you need to compile the SpatialIndex.cpp, rather than
> DiskSpatialIndex.cpp. They both have the same API, but only the first one
> compiles on Linux.
>
> Traian
>

Hello again Traian.
I was unable to make a full compilation on this provider. I'm attaching the
diff for SQLite provider and maybe you can point me where i get wrong.

[]'s

--
Helio Chissini de Castro
KDE Developer
Brasil/South America Primary Contact

[sqlite-provider.patch]

Index: Src/sqlite/CMakeLists.txt
===================================================================
--- Src/sqlite/CMakeLists.txt (revisão 4737)
+++ Src/sqlite/CMakeLists.txt (cópia de trabalho)
@@ -1,92 +1,99 @@
-
-add_library (sqlite-fdo
-alter.c
-analyze.c
-attach.c
-auth.c
-bitvec.c
-btmutex.c
-btree.c
-build.c
-backup.c
-callback.c
-complete.c
-date.c
-delete.c
-expr.c
-fault.c
-fts3.c
-fts3_expr.c
-fts3_hash.c
-fts3_icu.c
-fts3_porter.c
-fts3_tokenizer1.c
-fts3_tokenizer.c
-func.c
-global.c
-hash.c
-insert.c
-journal.c
-legacy.c
-loadext.c
-main.c
-malloc.c
-mem0.c
-mem1.c
-mem2.c
-mem3.c
-mem5.c
-memjournal.c
-mutex.c
-mutex_noop.c
-mutex_unix.c
-notify.c
-opcodes.c
-os.c
-os_unix.c
-pager.c
-parse.c
-pcache.c
-pcache1.c
-pragma.c
-prepare.c
-printf.c
-random.c
-resolve.c
-rowset.c
-rtree.c
-select.c
-shell.c
-status.c
-table.c
-tokenize.c
-trigger.c
-update.c
-utf.c
-util.c
-vacuum.c
-vdbeapi.c
-vdbeaux.c
-vdbeblob.c
-vdbe.c
-vdbemem.c
-vtab.c
-walker.c
-where.c
+set( sqlitefdo3_SRCS
+ alter.c
+ analyze.c
+ attach.c
+ auth.c
+ bitvec.c
+ btmutex.c
+ btree.c
+ build.c
+ backup.c
+ callback.c
+ complete.c
+ date.c
+ delete.c
+ expr.c
+ fault.c
+ fts3.c
+ fts3_expr.c
+ fts3_hash.c
+ fts3_icu.c
+ fts3_porter.c
+ fts3_tokenizer1.c
+ fts3_tokenizer.c
+ func.c
+ global.c
+ hash.c
+ insert.c
+ journal.c
+ legacy.c
+ loadext.c
+ main.c
+ malloc.c
+ mem0.c
+ mem1.c
+ mem2.c
+ mem3.c
+ mem5.c
+ memjournal.c
+ mutex.c
+ mutex_noop.c
+ mutex_unix.c
+ notify.c
+ opcodes.c
+ os.c
+ os_unix.c
+ pager.c
+ parse.c
+ pcache.c
+ pcache1.c
+ pragma.c
+ prepare.c
+ printf.c
+ random.c
+ resolve.c
+ rowset.c
+ rtree.c
+ select.c
+ shell.c
+ status.c
+ table.c
+ tokenize.c
+ trigger.c
+ update.c
+ utf.c
+ util.c
+ vacuum.c
+ vdbeapi.c
+ vdbeaux.c
+ vdbeblob.c
+ vdbe.c
+ vdbemem.c
+ vtab.c
+ walker.c
+ where.c
 )
 
-ADD_DEFINITIONS(-DSQLITE_ENABLE_COLUMN_METADATA
-                -DSQLITE_OMIT_TRACE
-                -DSQLITE_OMIT_EXPLAIN
-                -DSQLITE_OMIT_PROGRESS_CALLBACK
-                -DSQLITE_OMIT_AUTHORIZATION
-                -DSQLITE_OMIT_UTF16
-                -DSQLITE_OMIT_SHARED_CACHEXXX
-                -DSQLITE_THREADSAFE=2
-                -DSQLITE_ENABLE_RTREE
-                -DSQLITE_CORE
-                )
+add_definitions(
+ -DSQLITE_ENABLE_COLUMN_METADATA
+ -DSQLITE_OMIT_TRACE
+ -DSQLITE_OMIT_EXPLAIN
+ -DSQLITE_OMIT_PROGRESS_CALLBACK
+ -DSQLITE_OMIT_AUTHORIZATION
+ -DSQLITE_OMIT_UTF16
+ -DSQLITE_OMIT_SHARED_CACHEXXX
+ -DSQLITE_THREADSAFE=2
+ -DSQLITE_ENABLE_RTREE
+ -DSQLITE_CORE
+ )
 
-SET_TARGET_PROPERTIES( sqlite-fdo PROPERTIES COMPILE_FLAGS -fPIC)
+add_library ( sqlitefdo3 SHARED  ${sqlitefdo3_SRCS} )
 
+set_target_properties( sqlitefdo3 PROPERTIES VERSION 3 SOVERSION 6 )
 
+target_link_libraries( sqlitefdo3
+ pthread
+ dl
+ )
+
+
Index: Src/SpatialIndex/SpatialIndex.cpp
===================================================================
--- Src/SpatialIndex/SpatialIndex.cpp (revisão 4737)
+++ Src/SpatialIndex/SpatialIndex.cpp (cópia de trabalho)
@@ -19,6 +19,7 @@
 #include "stdafx.h"
 #include "SltGeomUtils.h"
 #include "SpatialIndex.h"
+#include <cstring>
 
 #ifndef _MSC_VER
 
Index: Src/SpatialIndex/SltGeomUtils.cpp
===================================================================
--- Src/SpatialIndex/SltGeomUtils.cpp (revisão 4737)
+++ Src/SpatialIndex/SltGeomUtils.cpp (cópia de trabalho)
@@ -20,6 +20,11 @@
 #include "SltGeomUtils.h"
 #include <math.h>
 
+#ifdef LINUX
+ #include <algorithm>
+ using namespace std;
+#endif // LINUX
+
 //For reference, duplicated from ogr_geometry.h
 ///**
 // * List of well known binary geometry types.  These are used within the BLOBs
Index: Src/SpatialIndex/CMakeLists.txt
===================================================================
--- Src/SpatialIndex/CMakeLists.txt (revisão 0)
+++ Src/SpatialIndex/CMakeLists.txt (revisão 0)
@@ -0,0 +1,23 @@
+include_directories(
+ ${CMAKE_CURRENT_SOURCE_DIR}
+ ${UNMANAGED_INCLUDE_DIR}
+ ${UTILITIES_COMMON_INCLUDE_DIR}
+ )
+
+set( SQLiteSpatialIndex_SRCS
+ SltGeomUtils.cpp  
+ stdafx.cpp
+)
+
+if( UNIX )
+ set( SQLiteSpatialIndex_Platform_SRCS SpatialIndex.cpp )
+else( UNIX )
+ set( SQLiteSpatialIndex_Platform_SRCS DiskSpatialIndex.cpp MappedFile.cpp )
+endif( UNIX )
+
+
+add_library( SQLiteSpatialIndex STATIC
+ ${SQLiteSpatialIndex_SRCS}  
+ ${SQLiteSpatialIndex_Platform_SRCS}
+ )
+

Mudanças de propriedades em: Src/SpatialIndex/CMakeLists.txt
___________________________________________________________________
Added: svn:eol-style
   + native

Index: Src/Provider/StringUtil.h
===================================================================
--- Src/Provider/StringUtil.h (revisão 4737)
+++ Src/Provider/StringUtil.h (cópia de trabalho)
@@ -212,7 +212,7 @@
 
     inline char* Data()
     {
-        return _buf ? _buf : "";
+        return _buf ? _buf : (char*)"";
     }
 
 private:
Index: Src/Provider/CMakeLists.txt
===================================================================
--- Src/Provider/CMakeLists.txt (revisão 4737)
+++ Src/Provider/CMakeLists.txt (cópia de trabalho)
@@ -1,28 +1,30 @@
+include_directories (
+ ${CMAKE_CURRENT_SOURCE_DIR}
+ ${UNMANAGED_INCLUDE_DIR}
+ ${UTILITIES_COMMON_INCLUDE_DIR}
+ ${UTILITIES_EXPRESSION_INCLUDE_DIR}
+ )
 
-include_directories (${SQLiteProvider_SOURCE_DIR}/sqlite-3.6.2
-                     ${SQLiteProvider_SOURCE_DIR}/SpatialIndex
-                     ${SQLiteProvider_SOURCE_DIR}/../../Fdo/Unmanaged/Inc
-                     ${SQLiteProvider_SOURCE_DIR}/../../Utilities/Common/Inc
-                     )
-link_directories (${SQLiteProvider_BINARY_DIR}/sqlite-3.6.2
-                  ${SQLiteProvider_SOURCE_DIR}/../../Fdo/Unmanaged/Src/.libs
-                  ${SQLiteProvider_SOURCE_DIR}/../../Utilities/Common/.libs
-                 )
+set( SQLiteProvider_SRCS
+ SltConversionUtils.cpp
+ slt.cpp
+ SltExprExtensions.cpp
+ SltMetadata.cpp
+ SltProvider.cpp
+ SltQueryTranslator.cpp
+ SltReader.cpp
+ SltSpatialContextReader.cpp
+ )
 
-add_library (SQLiteProvider SHARED
-SltConversionUtils.cpp
-slt.cpp
-SltExprExtensions.cpp
-SltMetadata.cpp
-SltProvider.cpp
-SltQueryTranslator.cpp
-SltReader.cpp
-SltSpatialContextReader.cpp
-)
+add_library (SQLiteProvider SHARED ${SQLiteProvider_SRCS} )
 
-target_link_libraries (SQLiteProvider SpatialIndex sqlite-fdo ProvidersCommon FDO )
+target_link_libraries ( SQLiteProvider
+ SQLiteSpatialIndex
+ sqlitefdo3
+ ProvidersCommon
+ FDO
+ )
 
-INSTALL (TARGETS SQLiteProvider
-         RUNTIME DESTINATION /usr/local/fdo-3.5.0/lib
-         LIBRARY DESTINATION /usr/local/fdo-3.5.0/lib
-         )
+set_target_properties( SQLiteProvider PROPERTIES VERSION ${FDO_VERSION} SOVERSION ${FDO_VERSION_MAJOR} )
+
+install( TARGETS SQLiteProvider DESTINATION ${LIB_INSTALL_DIR} )
Index: Src/CMakeLists.txt
===================================================================
--- Src/CMakeLists.txt (revisão 0)
+++ Src/CMakeLists.txt (revisão 0)
@@ -0,0 +1,10 @@
+include_directories(
+ ${CMAKE_CURRENT_SOURCE_DIR}/Inc
+ ${CMAKE_CURRENT_SOURCE_DIR}/SpatialIndex
+ ${CMAKE_CURRENT_SOURCE_DIR}/sqlite )
+
+# Provider uses a special modified version of sqlite
+add_subdirectory( sqlite )
+add_subdirectory( SpatialIndex )
+add_subdirectory( Provider )
+

Mudanças de propriedades em: Src/CMakeLists.txt
___________________________________________________________________
Added: svn:eol-style
   + native

Index: CMakeLists.txt
===================================================================
--- CMakeLists.txt (revisão 4734)
+++ CMakeLists.txt (cópia de trabalho)
@@ -1,9 +1,10 @@
+project(fdosqlite)
 
-cmake_minimum_required (VERSION 2.6)
-project (SQLiteProvider)
+# Make CPack available to easy generate binary packages
+include(CPack)
 
-add_subdirectory (sqlite)
-add_subdirectory (SpatialIndex)
-add_subdirectory (Provider)
+if( NOT FDO_CORE_BUILD )
+ find_package( FDO REQUIRED )
+endif( NOT FDO_CORE_BUILD )
 
-
+add_subdirectory( Src )


_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Traian Stanev

RE: SQLite Provider issue

Reply Threaded More More options
Print post
Permalink

Hi Helio,

I'm trying out the patch, but I get this problem when running the initial cmake on the SQLite provider. Let me know if you have any hints about how to work around it... I'll keep trying.

traian@macbooku:~/work/fdo/Providers/SQLite/slt_build$ /usr/bin/cmake ../
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
CMake Error at /usr/share/cmake-2.6/Modules/FindFDO.cmake:6 (cmake_policy):
  cmake_policy given unknown first argument "set"
Call Stack (most recent call first):
  CMakeLists.txt:7 (find_package)


-- Found FDO: /usr/local/lib/fdo-3.5.0/lib/libFDO.so
CMake Error in CMakeLists.txt:
  No cmake_minimum_required command is present.  A line of code such as

    cmake_minimum_required(VERSION 2.6)

  should be added at the top of the file.  The version specified may be lower
  if you wish to support older CMake versions for this project.  For more
  information run "cmake --help-policy CMP0000".


-- Configuring incomplete, errors occurred!




________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Helio Chissini de Castro [[hidden email]]
Sent: Thursday, June 04, 2009 3:01 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] SQLite Provider issue

Em Quinta-feira 04 de junho 2009, às 13:39:50, Traian Stanev escreveu:
> Hi Helio,
>
> For Linux, you need to compile the SpatialIndex.cpp, rather than
> DiskSpatialIndex.cpp. They both have the same API, but only the first one
> compiles on Linux.
>
> Traian
>

Hello again Traian.
I was unable to make a full compilation on this provider. I'm attaching the
diff for SQLite provider and maybe you can point me where i get wrong.

[]'s

--
Helio Chissini de Castro
KDE Developer
Brasil/South America Primary Contact
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Traian Stanev

RE: SQLite Provider issue

Reply Threaded More More options
Print post
Permalink

Never mind this, the patch didn't get applied correctly...

Traian

________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Traian Stanev
Sent: Thursday, June 04, 2009 9:07 PM
To: FDO Internals Mail List
Subject: RE: [fdo-internals] SQLite Provider issue

Hi Helio,

I'm trying out the patch, but I get this problem when running the initial cmake on the SQLite provider. Let me know if you have any hints about how to work around it... I'll keep trying.

traian@macbooku:~/work/fdo/Providers/SQLite/slt_build$ /usr/bin/cmake ../
-- The C compiler identification is GNU
-- The CXX compiler identification is GNU
-- Check for working C compiler: /usr/bin/gcc
-- Check for working C compiler: /usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
CMake Error at /usr/share/cmake-2.6/Modules/FindFDO.cmake:6 (cmake_policy):
  cmake_policy given unknown first argument "set"
Call Stack (most recent call first):
  CMakeLists.txt:7 (find_package)


-- Found FDO: /usr/local/lib/fdo-3.5.0/lib/libFDO.so
CMake Error in CMakeLists.txt:
  No cmake_minimum_required command is present.  A line of code such as

    cmake_minimum_required(VERSION 2.6)

  should be added at the top of the file.  The version specified may be lower
  if you wish to support older CMake versions for this project.  For more
  information run "cmake --help-policy CMP0000".


-- Configuring incomplete, errors occurred!




________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Helio Chissini de Castro [[hidden email]]
Sent: Thursday, June 04, 2009 3:01 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] SQLite Provider issue

Em Quinta-feira 04 de junho 2009, às 13:39:50, Traian Stanev escreveu:
> Hi Helio,
>
> For Linux, you need to compile the SpatialIndex.cpp, rather than
> DiskSpatialIndex.cpp. They both have the same API, but only the first one
> compiles on Linux.
>
> Traian
>

Hello again Traian.
I was unable to make a full compilation on this provider. I'm attaching the
diff for SQLite provider and maybe you can point me where i get wrong.

[]'s

--
Helio Chissini de Castro
KDE Developer
Brasil/South America Primary Contact
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Traian Stanev

RE: SQLite Provider issue

Reply Threaded More More options
Print post
Permalink
In reply to this post by Helio Chissini de Castro

Hi Helio,

I still can't get the new cmake files working on my system -- it seems like cmake can't find FDO, which I have successfully compiled and installed using cmake... I have cmake 2.6.2 if that makes any difference...

I will keep working on getting cmake to work for the provider, but in the meanwhile, one thing I discovered is that for 32 bit builds, you have to explicitly tell g++ to enable SSE and SSE2. Some code in the provider uses SSE2 so it needs to be turned on, I'm guessing by using --enable-sse and --enable-sse2 options. I originally compiled on x64, where SSE is automatically always available, so I did not notice that problem.


Traian


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Helio Chissini de Castro
Sent: Thursday, June 04, 2009 3:01 PM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] SQLite Provider issue

Em Quinta-feira 04 de junho 2009, às 13:39:50, Traian Stanev escreveu:
> Hi Helio,
>
> For Linux, you need to compile the SpatialIndex.cpp, rather than
> DiskSpatialIndex.cpp. They both have the same API, but only the first
> one compiles on Linux.
>
> Traian
>

Hello again Traian.
I was unable to make a full compilation on this provider. I'm attaching the diff for SQLite provider and maybe you can point me where i get wrong.

[]'s

--
Helio Chissini de Castro
KDE Developer
Brasil/South America Primary Contact

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Helio Chissini de Castro

Re: SQLite Provider issue

Reply Threaded More More options
Print post
Permalink
Em Sexta-feira 05 de junho 2009, às 11:44:06, Traian Stanev escreveu:

> Hi Helio,
>
> I still can't get the new cmake files working on my system -- it seems like
> cmake can't find FDO, which I have successfully compiled and installed
> using cmake... I have cmake 2.6.2 if that makes any difference...
>
> I will keep working on getting cmake to work for the provider, but in the
> meanwhile, one thing I discovered is that for 32 bit builds, you have to
> explicitly tell g++ to enable SSE and SSE2. Some code in the provider uses
> SSE2 so it needs to be turned on, I'm guessing by using --enable-sse and
> --enable-sse2 options. I originally compiled on x64, where SSE is
> automatically always available, so I did not notice that problem.
>

Hi Traian
My default devel machine is 64 bits, anyway.
I forgot to tell that the provider need to be inside main code yet ( can't be
standalone dor now ).
To make things easier, i will commit the patch now and  we can solving  this
after. So, on the main fdo checkout. just run cmake -DWITH_PROVIDERS="SQLite"
and should be enough. FindFDO.cmake is under cmake/modules and after i have
all providers done, i will make it instalable on global dir

[]'s

--
Helio Chissini de Castro
KDE Developer
Brasil/South America Primary Contact
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals
Traian Stanev

RE: SQLite Provider issue

Reply Threaded More More options
Print post
Permalink

OK thanks, that's the part I was missing. I will try running within the main FDO build. You can commit the patch now, then we fix it after.

Traian


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Helio Chissini de Castro
Sent: Friday, June 05, 2009 11:51 AM
To: FDO Internals Mail List
Subject: Re: [fdo-internals] SQLite Provider issue

Em Sexta-feira 05 de junho 2009, às 11:44:06, Traian Stanev escreveu:

> Hi Helio,
>
> I still can't get the new cmake files working on my system -- it seems like
> cmake can't find FDO, which I have successfully compiled and installed
> using cmake... I have cmake 2.6.2 if that makes any difference...
>
> I will keep working on getting cmake to work for the provider, but in the
> meanwhile, one thing I discovered is that for 32 bit builds, you have to
> explicitly tell g++ to enable SSE and SSE2. Some code in the provider uses
> SSE2 so it needs to be turned on, I'm guessing by using --enable-sse and
> --enable-sse2 options. I originally compiled on x64, where SSE is
> automatically always available, so I did not notice that problem.
>
Hi Traian
My default devel machine is 64 bits, anyway.
I forgot to tell that the provider need to be inside main code yet ( can't be
standalone dor now ).
To make things easier, i will commit the patch now and  we can solving  this
after. So, on the main fdo checkout. just run cmake -DWITH_PROVIDERS="SQLite"
and should be enough. FindFDO.cmake is under cmake/modules and after i have
all providers done, i will make it instalable on global dir

[]'s

--
Helio Chissini de Castro
KDE Developer
Brasil/South America Primary Contact
_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals

_______________________________________________
fdo-internals mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fdo-internals