I've used the "amalgam" approach for a while, and even opened tickets on it to make it easier for me to do so ( http://www.sqlite.org/cvstrac/tktview?tn=2194)
What I've usually done is simply created a single .c file that #include'd all the other .c files such as: #include <alter.c> #include <analyze.c> #include <attach.c> ... 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. Perhaps a middle of the road approach like this could be used? On 5/2/07, Clark Christensen <[EMAIL PROTECTED]> wrote:
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, with 3.3.15 and 3.3.16, I have to manually add "sqlite3_io_trace" to sqlite3.def to get the shell to link into sqlite3.exe. Otherwise, it fails with an "unresolved external..." error. This is on Windows XP and MS VC6 using the pre-processed C source distro. shell.c was generated on my Linux box (Red Hat 7.2) using "make target_source" after running the configure script in the "regular" source distro. The same link error occurs using the sqlite3.def file from the precompiled Windows DLL distro file. Thanks! -Clark ----- Original Message ---- From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> To: [email protected] Sent: Wednesday, May 2, 2007 7:53:35 AM Subject: Re: [sqlite] May I ask why the source distribution mechanism was changed starting with 3.3.14? "C.Peachment" <[EMAIL PROTECTED]> wrote: > > After clearing these warnings, I discovered that the Pelles C > compiler was unable to complete the compilation of sqlite3.c > and timed out after 300 seconds. So it appears that I need > to revert to separate source files that were available with > earlier versions of sqlite3. > I consider this to be a bug in Pelles C. It refuses to compile a valid ANSI C program. On the other hand, this is the first argument in favor of separate source files that makes sense to me. -- D. Richard Hipp <[EMAIL PROTECTED]> ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] ----------------------------------------------------------------------------- ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
