Re: [sqlite] Cannot get amalgamation built from CVS to compile

2008-05-13 Thread Matthew L. Creech
On Tue, May 13, 2008 at 12:28 AM, Samuel Neff <[EMAIL PROTECTED]> wrote:
>
>  One other issue we're having and are not sure about is we get a compiler
>  error on sqlite3_profile and sqlite3_trace.  We need to remove these two
>  lines from the def file included with the sqlite source in order to get
>  everything to compile ok on VS 2008.  are sqlite3_profile and sqlite3_trace
>  included by default in both the source and def or is there a mismatch?  Or
>  is there something else we should be doing besides editing the def file
>  manually?
>

Presumably you're either defining SQLITE_OMIT_TRACE or
SQLITE_OMIT_FLOATING_POINT, which omits both of those functions from
the build, and since sqlite3.def is static it has to be updated.  I'd
hazard a guess that updating it yourself is currently required, but I
don't build on Windows, so I'm really not sure - DRH would know more
about this.

The makefile does have a target to re-generate sqlite3.def on the fly,
but that's meant for Cygwin-based builds.

-- 
Matthew L. Creech
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] Cannot get amalgamation built from CVS to compile

2008-05-12 Thread Samuel Neff
Matthey,

Thanks for making this change.  We got latest from CVS today and
configure/make worked great.

One other issue we're having and are not sure about is we get a compiler
error on sqlite3_profile and sqlite3_trace.  We need to remove these two
lines from the def file included with the sqlite source in order to get
everything to compile ok on VS 2008.  are sqlite3_profile and sqlite3_trace
included by default in both the source and def or is there a mismatch?  Or
is there something else we should be doing besides editing the def file
manually?

Best regards,

Sam


On Tue, May 6, 2008 at 10:48 PM, Matthew L. Creech <[EMAIL PROTECTED]>
wrote:

> In the latest CVS, you should now also be able to do what you intended
> in the first place.  Namely:
>
> ./configure
> make sqlite3.c
>
> I thought about it, and there's no good reason to inline the
> auto-generated config.h file in to the amalgamation like we were
> doing, so now it keeps it as an #include that's only performed if
> building in-tree.  Let me know if you see any more problems.
>
> --
> Matthew L. Creech
>



-- 
-
We're Hiring! Seeking passionate Flex, C#, or C++ (RTSP, H264) developer.
Position is in the Washington D.C. metro area. Contact
[EMAIL PROTECTED]
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] Cannot get amalgamation built from CVS to compile

2008-05-06 Thread Matthew L. Creech
In the latest CVS, you should now also be able to do what you intended
in the first place.  Namely:

./configure
make sqlite3.c

I thought about it, and there's no good reason to inline the
auto-generated config.h file in to the amalgamation like we were
doing, so now it keeps it as an #include that's only performed if
building in-tree.  Let me know if you see any more problems.

-- 
Matthew L. Creech
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] Cannot get amalgamation built from CVS to compile

2008-05-06 Thread Samuel Neff
Matthew,

Thanks!  After deleting everthing and re-checking out from cvs, using the
pre-build makefile worked great.

Best regards,

Sam


On Tue, May 6, 2008 at 4:46 PM, Matthew L. Creech <[EMAIL PROTECTED]>
wrote:

>
> If you want to create a generic amalgamation (without pre-defined
> features like HAVE_STDINT_H), at least currently, you shouldn't use
> the configure script to generate your makefile, since the point of
> using autoconf is to detect resources (header files, etc.) that aren't
> portable.  You can instead start with the pristine source, then:
>
> cp Makefile.linux-gcc Makefile
> make sqlite3.c
>
> bypassing the configure script altogether.  That should do what you want
>
> --
> Matthew L. Creech
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>



-- 
-
We're Hiring! Seeking passionate Flex, C#, or C++ (RTSP, H264) developer.
Position is in the Washington D.C. metro area. Contact
[EMAIL PROTECTED]
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] Cannot get amalgamation built from CVS to compile

2008-05-06 Thread Matthew L. Creech
On Tue, May 6, 2008 at 4:38 PM, Samuel Neff <[EMAIL PROTECTED]> wrote:
>
>  we ran
>
>  configure
>  make sqlite3.c
>
>  and got an amalgamation with those types defined using unmodified sources
>  from CVS.  Are you saying the types should not be defined?

No - you got what I'd expect: #defines added for all the features of
your local system that the configure script detected.  Since it's a
Linux box, that will include HAVE_GMTIME_R as well as HAVE_STDINT_H.

>
>  We modified the sqlite3.c file by hand as Brad suggested and it compiles and
>  runs fine, but I agree with Brad that it seems odd to need to edit the file
>  manually.
>

If you want to create a generic amalgamation (without pre-defined
features like HAVE_STDINT_H), at least currently, you shouldn't use
the configure script to generate your makefile, since the point of
using autoconf is to detect resources (header files, etc.) that aren't
portable.  You can instead start with the pristine source, then:

cp Makefile.linux-gcc Makefile
make sqlite3.c

bypassing the configure script altogether.  That should do what you want

-- 
Matthew L. Creech
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] Cannot get amalgamation built from CVS to compile

2008-05-06 Thread Samuel Neff
On Tue, May 6, 2008 at 2:42 PM, Matthew L. Creech <[EMAIL PROTECTED]>
wrote:

>
>
> By default things like HAVE_GMTIME_R aren't defined, so you'd have to
> add those to your CPPFLAGS or something if you wanted to build a
> generic amalgamation with those features included.  The datatypes that
> aren't defined will use less accurate types that are "good enough", so
> that e.g. UINT32_T might be "unsigned long" rather than "uint32_t",
> which might be 64 bits.  This is under discussion right now: whether
> we even need the specifically-sized types at all.  If not, the
> inclusion of  and definition of those types may disappear in
> the interest of portability.
>
> --
> Matthew L. Creech


we ran

configure
make sqlite3.c

and got an amalgamation with those types defined using unmodified sources
from CVS.  Are you saying the types should not be defined?

We modified the sqlite3.c file by hand as Brad suggested and it compiles and
runs fine, but I agree with Brad that it seems odd to need to edit the file
manually.

Thanks,

Sam



-- 
-
We're Hiring! Seeking passionate Flex, C#, or C++ (RTSP, H264) developer.
Position is in the Washington D.C. metro area. Contact
[EMAIL PROTECTED]
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] Cannot get amalgamation built from CVS to compile

2008-05-06 Thread Matthew L. Creech
On Tue, May 6, 2008 at 11:22 AM, Brad House
<[EMAIL PROTECTED]> wrote:
> We ran into the same problem here.  It seems as though maybe the
>  amalgamation is hand-edited for distribution to remove the contents
>  of the config.h to be system agnostic.  When we built ours from CVS,
>  we just did the same hand-edit and packaged it and it compiled fine on the
>  dozen or so OS's we distribute binaries for (Windows (32 & 64), MacOSX,
>  Linux, FreeBSD, Solaris, SCO, AIX, ...).
>
>  I'd actually like to know the consequences of this though, especially
>  in relation to the reentrant functions (HAVE_GMTIME_R, HAVE_LOCALTIME_R),
>  also I'd be interested to know what it does without UINT64_T or UINTPTR_T...
>

By default things like HAVE_GMTIME_R aren't defined, so you'd have to
add those to your CPPFLAGS or something if you wanted to build a
generic amalgamation with those features included.  The datatypes that
aren't defined will use less accurate types that are "good enough", so
that e.g. UINT32_T might be "unsigned long" rather than "uint32_t",
which might be 64 bits.  This is under discussion right now: whether
we even need the specifically-sized types at all.  If not, the
inclusion of  and definition of those types may disappear in
the interest of portability.

-- 
Matthew L. Creech
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] Cannot get amalgamation built from CVS to compile

2008-05-06 Thread Brad House
We ran into the same problem here.  It seems as though maybe the
amalgamation is hand-edited for distribution to remove the contents
of the config.h to be system agnostic.  When we built ours from CVS,
we just did the same hand-edit and packaged it and it compiled fine on the
dozen or so OS's we distribute binaries for (Windows (32 & 64), MacOSX,
Linux, FreeBSD, Solaris, SCO, AIX, ...).

I'd actually like to know the consequences of this though, especially
in relation to the reentrant functions (HAVE_GMTIME_R, HAVE_LOCALTIME_R),
also I'd be interested to know what it does without UINT64_T or UINTPTR_T...

-Brad

Samuel Neff wrote:
> We're trying to build an amalgamation from CVS to use within our application
> for the first time.  However, when we try to compile we get an error on this
> line:
> 
> 
> #ifdef HAVE_STDINT_H
> #include 
> #endif
> 
> fatal error C1083: Cannot open include file: 'stdint.h': No such file or
> directory
> 
> 
> We tracked back the difference between that distribution and the
> amalgamation that we build and the major changes start here
> 
> From sqlite3.c in 3.5.8 distribution:
> 
> #ifndef _CONFIG_H_
> #define _CONFIG_H_
> 
> /* We do nothing here, since no assumptions are made by default */
> 
> #endif
> 
> 
> From sqlite3.c in our amalgamation built from CVS:
> 
> 
> #ifndef _CONFIG_H_
> #define _CONFIG_H_
> 
> 
> 
> /*
> ** Data types
> */
> 
> /* Define as 1 if you have the int8_t type */
> #define HAVE_INT8_T 1
> 
> ...
> 
> /* Define as 1 if you have the stdint.h header */
> #define HAVE_STDINT_H 1
> 
> ...
> 
> /* End of header */
> #endif
> 
> 
> Is this related to a change in the CVS source or is there something we're
> doing wrong in building the amalgamation?
> 
> We're building the amalgmation on Fedora Core release 4 (Stentz),
> 2.6.17-1.2142_FC4smp #1 SMP i686 i686 i386 GNU/Linux
> 
> We're compiling sqlite in Microsoft Visual Studio 2008 as part of
> System.Data.SQLite (.NET) which uses sqlite3.c and compiles fine with
> sqlite3.c from the 3.5.8 distribution on the sqlite.org website.
> 
> Any help would be appreciated.
> 
> Thanks,
> 
> Sam
> 
> 
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] Cannot get amalgamation built from CVS to compile

2008-05-06 Thread Matthew L. Creech
On Tue, May 6, 2008 at 10:49 AM, Samuel Neff <[EMAIL PROTECTED]> wrote:
>
>  Is this related to a change in the CVS source or is there something we're
>  doing wrong in building the amalgamation?
>
>  We're building the amalgmation on Fedora Core release 4 (Stentz),
>  2.6.17-1.2142_FC4smp #1 SMP i686 i686 i386 GNU/Linux
>
>  We're compiling sqlite in Microsoft Visual Studio 2008 as part of
>  System.Data.SQLite (.NET) which uses sqlite3.c and compiles fine with
>  sqlite3.c from the 3.5.8 distribution on the sqlite.org website.
>

Fhe configure script is picking up standard headers like  on
Linux which aren't supported in Visual Studio.

If you want to build the amalgamation on Linux without detecting
Linux-supported headers, you don't need to use autoconf - try:

1. Unpack the source tarball
2. cp Makefile.linux-gcc Makefile
3. make sqlite3.c

-- 
Matthew L. Creech
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users


Re: [sqlite] Cannot get amalgamation built from CVS to compile

2008-05-06 Thread Darko Miletic
Samuel Neff wrote:
> We're trying to build an amalgamation from CVS to use within our application
> for the first time.  However, when we try to compile we get an error on this
> line:
> 
> 
> #ifdef HAVE_STDINT_H
> #include 
> #endif
> 
> fatal error C1083: Cannot open include file: 'stdint.h': No such file or
> directory

What version of gcc does Fedora core 4 contains? If it is 3.x I do not 
think that one ships with C99 compliant C standard library of which 
stdint.h is part.

You should probably make sure that both HAVE_INT8_T and HAVE_STDINT_H 
are set to 0 if this turns out to be the case.

On the other hand if fedora core 4 has gcc 4.x with C99 standard C 
library than you should checkout your include path's.

Use locate command to find where is stdint.h and make sure to pass that 
folder to gcc in -I directive




___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users