I did a comparison some time back between gcc and IBM's Xlc. The IBM
compiler was a bit slower to compile but the fully optimized executables
were quite different in performance. Xlc's executable ran 40% faster.
A look at the generated code showed that the IBM optimizer was carefully
matched
time gcc -m32 -O2 -I. -I../sqliteSrc/sqlite-3.3.17/src -DNDEBUG -DTHREADSAFE=1
-DSQLITE_THREAD_OVERRIDE_LOCK=-1 -DSQLITE_OMIT_LOAD_EXTENSION=1 -c sqlite3.c
-fPIC -DPIC -o .libs/sqlite3.o
real0m20.266s
user0m19.773s
sys 0m0.444s
time gcc -m32 -O2 -I.
"C.Peachment" <[EMAIL PROTECTED]> wrote:
> With the suggestion that the problem was a compiler bug
> in PellesC for Windows, I posted a message on their forum.
> One response suggested a couple of configuration changes
> and also said to wait a while because it took a long time to
> compile.
>
Ulrich Telle wrote:
drh wrote:
I'm still having trouble trying to understand how managing
60 separate code files is perceived to be easier than managing
just 2 files (sqlite3.c and sqlite3.h). It seems to me that
the management problem gets much easier the fewer files there
are to manage.
With the suggestion that the problem was a compiler bug
in PellesC for Windows, I posted a message on their forum.
One response suggested a couple of configuration changes
and also said to wait a while because it took a long time to
compile.
So, I let the compiler continue after it had reported a
On 5/4/07, Ken <[EMAIL PROTECTED]> wrote:
100% concur with Dennis.
Thanks again for a great product!
+1
I couldn't said it better, maybe even in my native language ;-)
Best regards,
~Nuno Lucas
Dennis Cote <[EMAIL PROTECTED]> wrote: [EMAIL PROTECTED] wrote:
>
> Can somebody please
100% concur with Dennis.
Thanks again for a great product!
Dennis Cote <[EMAIL PROTECTED]> wrote: [EMAIL PROTECTED] wrote:
>
> Can somebody please explain to my how 2 files is less manageable
> than 60?
>
>
>
Richard,
I think part of the problem is simple inertia. Some people have
[EMAIL PROTECTED] wrote:
"Shane Harrelson" <[EMAIL PROTECTED]> wrote:
This allowed me to get the benefits of the single source file (more compiler
optimizations, etc.) while keeping the manageability, etc. of the separate
source file.
I'm still having trouble trying to understand how
[EMAIL PROTECTED] wrote:
Can somebody please explain to my how 2 files is less manageable
than 60?
Richard,
I think part of the problem is simple inertia. Some people have
developed a methodology for using the sqlite source files based on the
previous arrangement. They may have
drh wrote:
> I'm still having trouble trying to understand how managing
> 60 separate code files is perceived to be easier than managing
> just 2 files (sqlite3.c and sqlite3.h). It seems to me that
> the management problem gets much easier the fewer files there
> are to manage.
In the case
On Fri, May 04, 2007 at 14:04:24 +, [EMAIL PROTECTED] wrote:
> Can somebody please explain to my how 2 files is less manageable
> than 60?
To my mind, the only missing feature is CPP #line directives, like
#line 1 "alter.c"
when contents of alter.c begins. If they are in place,
Richard,
For what it's worth, it would be very convenient to have shell.c included in
the preprocessed source distro.
sqlite3.def would also be convenient, but the
nm sqlite3.o | grep ... | sed ... >>sqlite3.def
method seems to correctly generate sqlite3.def on my Windows system - EXCEPT,
Hello Dr. Hipp:
I have previously reported compiler warnings to you issued
by the Pelles C MS-Windows compiler and you have repaired
them in the following release. This is the first time I have tried
to compile the single file sqlite3.c using the compiler version 3.50
and it reported some
The preprocessed source code in single files (plus def file) package
would be appreciated.
The number one reason for me, which make the "The Amalgamation" a show stopper:
Using SQLite in an open source project usually (and also in my case)
means that the source code is available on a
Hello drh,
I'm happy with the new source release method. I was fine with the old
way too. The new method is slightly more convenient for me when I
upgrade.
C
Monday, April 30, 2007, 5:46:19 PM, you wrote:
dhc> Martin Jenkins <[EMAIL PROTECTED]> wrote:
>>
>> As fas as I know, the dev team is
[EMAIL PROTECTED] wrote:
Martin Jenkins <[EMAIL PROTECTED]> wrote:
I agree, it is slightly odd for neither of them to reply.
Why is it odd?
Because you normally reply to these things, if only to say something lie
"the pre-processed source for Windows is provided as a courtesy". ;)
We
-Mensagem original-
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Enviada em: segunda-feira, 30 de abril de 2007 18:46
Para: sqlite-users@sqlite.org
Assunto: Re: [sqlite] May I ask why the source distribution mechanism was
changed starting with 3.3.14?
Martin Jenkins <[EMAIL
-Mensagem original-
De: Bennett, Patrick [mailto:[EMAIL PROTECTED]
Enviada em: segunda-feira, 30 de abril de 2007 19:28
Para: sqlite-users@sqlite.org
Assunto: RE: [sqlite] May I ask why the source distribution mechanism was
changed starting with 3.3.14?
People (myself being one of
People (myself being one of them) were asking if it could be put back
the way it was.
Several of us (those that replied at least) stated our dislike of the
new single .c file format.
It was also a question (hence the subject line). No one ever replied.
It seemed like something worthy of at
Martin Jenkins <[EMAIL PROTECTED]> wrote:
>
> As fas as I know, the dev team is Dr Hipp and Dan Kennedy (apologies if
> there's someone else and I missed you) and I agree, it is slightly odd
> for neither of them to reply.
>
Why is it odd? The issue is not something that needs replying
to.
-Mensagem original-
De: Martin Jenkins [mailto:[EMAIL PROTECTED]
Enviada em: segunda-feira, 30 de abril de 2007 18:25
Para: sqlite-users@sqlite.org
Assunto: Re: [sqlite] May I ask why the source distribution mechanism was
changed starting with 3.3.14?
Bennett, Patrick wrote:
> I
Bennett, Patrick wrote:
I wasn't sure who maintained the binary distribution and based on the
recent list activity, I assumed someone who was responsible would've
already replied.
As fas as I know, the dev team is Dr Hipp and Dan Kennedy (apologies if
there's someone else and I missed you)
Ok, thanks for pointing that out.
I wasn't sure who maintained the binary distribution and based on the
recent list activity, I assumed someone who was responsible would've
already replied.
Patrick
-Original Message-
From: Martin Jenkins [mailto:[EMAIL PROTECTED]
Sent: Monday, April
Bennett, Patrick wrote:
No comment at all? That's three users asking for this now. :(
Dr Hipp usually responds pretty quickly, but sometimes he's away on
business. You know, supporting the paying customers... ;)
Martin
No comment at all? That's three users asking for this now. :(
Patrick
-Original Message-
From: Clark Christensen [mailto:[EMAIL PROTECTED]
Sent: Friday, April 27, 2007 11:12 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] May I ask why the source distribution mechanism
was
Please provide the processed source package, as it has been the case
for SQLite before.
"The Amalgamation" big c file (plus header file) might be an
(optional) neat package, but the standard processed source package
shall be still available.
The http://www.sqlite.org/sqlite-source-3_3_17.zip
In general, I agree. I miss the zipped set of pre-processed C source.
Since you have the Linux-based build system at your disposal, you can get what
you're used to having with
make target_source
on the Linux system. This creates a tsrc directory containing the familiar
pre-processed C
The last time I downloaded SQLite was version 3.3.12.
For that version (and many prior versions), I could download a
preprocessed archive containing all of the source code, except parse.h,
parse.c and opcode.h(? - this is from memory) were the 'generated'
versions.
The source for the command-line
28 matches
Mail list logo
