[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 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.
I know that for my own projects, the use of the amalgamation
has greatly simplified configuration management. Now I have
just two files (sqlite3.[ch]) that I drop into my project
and I'm done. Before I had to either create an external
dependency on a external SQLite library and manage that,
or import 60+ code files in to a subdirectory with its own
makefile, etc. What a pain.
Chris Peachment points out that his "Pelles C" compiler (never
heard of that one before, but presumably it has its purposes)
is unable to compile sqlite3.c, presumably because the file
is is too large. This is the only reason I have heard yet
for wanting to use separate source file that makes any sense
to me.
Can somebody please explain to my how 2 files is less manageable
than 60?
Having multiple files means that there is sub-division of purpose. If there
is known to be a problem with the function handling then one can find the
code in func.c. Recompilation times can be considerably less if changes can
be isolated to 1 file out of 60, with the remaining 59 being unchanged and
therefore not requiring recompilation. With an amalgamation, one is forced
to recompile the entire project for any single change.
I would have thought that if you were so convinced that the reduced numbers
of files were easier then you would have abandoned the distribution which
used 60 files entirely, and switched to developing with just the 2 files.
That you have not leads me to think that you find the 60 files more
manageable than 2.
In your example above you've cited that dropping a pair of files on to your
project has made things easier for you. I don't doubt this and I quite
agree. Personally I feel that having a dependency on a library is far more
desireable for a project, rather than direct inclusion of the source, but
that's a build issue, rather than a distribution issue. However, the point
you're making is from a black-box user's point of view. The user doesn't
care how it works or what it does, but just that it does what they want.
Other users - those who don't treat it as a black box and wish to extend
functionality or develop more usefully from the code base, and those who are
(because of the environment they must work in) forced to make changes to the
sources - are far more comfortable with a distribution that contains
multiple files split up as a developer might want to work with.
I would have said that there is scope for the 3 different forms of
distribution :
* The base distribution that is used for users who can run the parser.
* The pre-processed distribution, as before, for those users who wish to
work with the sources, but don't necessarily want to (or are unable to,
because of their environment) run the parser.
* The amalgamation distribution, as we have now, for those users who
treat the database as a black-box and never wish to know any more than that
it compiled and works.
--
Justin Fletcher, Senior Software Engineer
Picsel Technologies Ltd Tel: +44 141 8855588
Titanium House, Kings Inch Rd, Glasgow, G51 4BP, UK Web: www.picsel.com
----------------------------------------------------------------------------
This email is subject to disclaimer at http://www.picsel.com/disclaimer.html
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
