Total Lines Of Code: 3200 (2003-07-11 20:29)
Summary Period: 2002-12-21 to 2003-06-27
Total Lines Of Code:
3200 (2003-07-11 20:29)
| Author | Changes | Lines of code | Lines per change |
|---|---|---|---|
| Totals | 73 (100.0%) | 3503 (100.0%) | 47.9 |
| sunshine | 48 (65.8%) | 2907 (83.0%) | 60.5 |
| gblock | 5 (6.8%) | 490 (14.0%) | 98.0 |
| matzebraun | 8 (11.0%) | 49 (1.4%) | 6.1 |
| res2002 | 8 (11.0%) | 34 (1.0%) | 4.2 |
| jorrit | 1 (1.4%) | 19 (0.5%) | 19.0 |
| philwyett | 1 (1.4%) | 2 (0.1%) | 2.0 |
| thebolt00 | 1 (1.4%) | 1 (0.0%) | 1.0 |
| okt | 1 (1.4%) | 1 (0.0%) | 1.0 |
Eric Sunshine fixed silly bug in csLoadLibrary() for MacOS/X. It was
supposed to transform the incoming .csplugin suffix on the pathname with
.csbundle, but instead uselessly replaced .csplugin with .csplugin.
1 lines of code changed in:
Forgot to commit fix for compilation warning.
1 lines of code changed in:
Eric Sunshine made the following changes:
-*- Renamed csGetAppPath() to csGetAppDir() to better reflect its
function.
-*- Added a new csGetAppPath() which returns the actual absolute path to
the executable (as opposed to csGetAppDir() which returns the
directory containing the executable).
-*- Added csGetResourceDir() as complement of csGetAppDir(). On many
platforms, the resource path is the same as the application path, but
this might not be true for all platforms. For instance, on MacOS/X,
csGetAppDir() needs to return the directory in which the .app wrapper
is contained, however csGetResourceDir() needs to return the Resources
directory inside the wrapper.
-*- Added platform-specific csGetAppDir() and csGetResourceDir() for
MacOS/X.
-*- Updated the generic csGetPluginPaths() so that it includes the result
of csGetResourceDir() in the plugin path list.
-*- The above changes should allow the MacOS/X port to once again locate
its plugin modules.
-*- Fixed bug: In the case of a bare program name as argv[0] (as opposed
to an absolute or relative path), the default csGetAppDir() in
cssys/general simply returned the first component of PATH which
actually existed, rather than returning the component of PATH which
contained the application.
-*- Fixed bug: The default csGetAppDir() in cssys/general was always using
';' as the path delimiter, even though that only works for Windows.
Now uses ':' for Unix and Unix-like platforms.
-*- Fixed bug: The default csGetPluginPaths() in cssys/general was
attempting to prevent pushing "/" onto the plugin path list (because
"/" has ambiguous meaning under Windows), but was instead actually
preventing addition of any absolute path to the list (that is, any
path beginning with "/").
-*- Renamed iCommandLineParser::GetAppPath() to GetAppDir() to better
reflect its function.
129 lines of code changed in:
Eric Sunshine eliminated a few instances of NULL which had creeped back
into the project.
2 lines of code changed in:
Made the following changes:
- Added a few helpers to deal with native paths and plugin paths.
- All platforms now use the same plugin paths:
<app dir>, $CRYSTAL/lib, $CRYSTAL/crystal, $CRYSTAL
(where $CRYSTAL is the CS installation dir)
2 lines of code changed in:
Eric Sunshine fixed several problems recently introduced into
csLoadLibrary() in OSXDynamicLibrary.cpp:
-*- Compilation error: Incoming argument did not match variable name used
in code.
-*- Run-time failure: Was using a lot of hard-coded constants for path
dissection, but the constants were incorrect.
-*- Memory trashing: Was not allocating sufficient memory for the working
path buffer, thus corrupting memory beyond end of buffer.
-*- Memory leak: Was leaking the working buffer.
25 lines of code changed in:
Fixed wrong csGetPluginPaths().
9 lines of code changed in:
Removed find library stuff, changed csLoadLibrary() to use fully qualified paths.
19 lines of code changed in:
- Marten added the class csProcessorCapabilities to allow CS to query processorspecific extensions and information. Some functions in this class is processorspecific and some parts compilerdependnat so we must protect certain areas with #defines
1 lines of code changed in:
Changed the way how SCF plugin scanning works:
- Moved scanning invokation to scfInitialize().
- A platform-dependent function, csScanPluginsDir(), returns
plugin filenames and metadata.
- Such a function is provided for Win32. For unix and macosx,
the "old" function that scans for .csplugin files is used.
Made the following changes:
- The DirectDraw configure time test now also tests for
DirectSound, and thus changed the makefile var nomenclature to
"DirectX".
- Slight changed the way DLLs are loaded on Win32: now
LoadLibraryEx() is used with a flag which causes Windows to
first look for the actual file in the specified directory.
- On Win32, plugin metadata is now contained inside the DLL.
Worked around problems with static linking. Specifically, it was
assumed that a factory function is always only used for a single
class. This is not always the case (e.g. the bezier loader.)
1 lines of code changed in:
Oops. Forgot the old make system. :)
0 lines of code changed in:
iChecking in an implementation for MacOS/X to use the NSUserDefaults API
to load/store user preferences.
MacOS/X will now store user preferences on a per-application basis into
~/Library/Preferences, stored in the standard preferences format by the OS.
Multiple configuration files are used; they are named as following:
"Generic" CrystalSpace configuration data (per-user): CrystalSpace.Generic
App-specific: CrystalSpace.<appname>
For example:
bash% defaults read CrystalSpace.Walktest
{
"Video.OpenGL.ClipOptional" = NSP;
"Video.OpenGL.ClipOuter" = pSZ;
"Video.OpenGL.ClipRequired" = SPp;
}
As you can see, the key/value pairs are stored in the defaults database according
to the normal preferences behavior.
These preference files will be read on creation of an iDefaultsConfig object and
the 'Open()' call tells it which domain you're interested in reading.
Application initialization is responsible for providing the appropriate keys to read.
470 lines of code changed in:
moved platformconfig.cpp to general as the macosx target is also using it at the moment and maybe other posix like systems will too
1 lines of code changed in:
Completely banished user.cfg from all spheres of
csInitializer::SetupConfigManager() and out of reach of mortal
beings. Also changed OS/X makefile to use the Unix platform
configuration (in lack of a special OS/X variant.)
1 lines of code changed in:
More forgotten commits.
Minor typo fixes.
1 lines of code changed in:
Added a forward declaration of iConfigFile.
1 lines of code changed in:
Eric Sunshine performed Phase One of the elimination of the monolithic
scf.cfg:
-*- Plugin modules are now self-describing. This information can be
queried at run-time without having to actually load the module.
-*- The plugin maintainer now manages the plugin's meta-information in an
external .csplugin file, rather than hard-coding the information into
the plugin's source code. The mechanism by which the meta-information
is bound to the plugin is platform-dependent. Presently, all
platforms simply lay down the meta-information in a plain text file
alongside the plugin itself; with the same basename and extension
.csplugin. This may change in the future. For example, on MacOS/X,
the meta-information will probably be encapsulated within the plugin's
bundle wrapper.
-*- Plugin meta-information is now maintained in XML format. Here is an
example:
<?xml version="1.0"?>
<!-- gl3d.csplugin -->
<plugin>
<name>gl3d</name>
<scf>
<classes>
<class>
<name>crystalspace.graphics3d.opengl</name>
<description>OpenGL 3D graphics driver</description>
<requires>
<class>crystalspace.font.server.</class>
</requires>
</class>
</classes>
</scf>
</plugin>
-*- Since meta-information is now extensible, maintainers can choose to
publish supplementary information about plugins (in addition to the
SCF information already published). For example, image loading
plugins could publish "image indendification" information which would
allow the image loading multiplexor to selectively request image
loading plugins on-demand, rather than requesting all plugins
unconditionally, even if they are not needed. Here is an example of a
possible meta-information table for the PNG loader:
<?xml version="1.0"?>
<!-- cspngimg.csplugin -->
<plugin>
<name>cspngimg</name>
<scf>...</scf>
<imageloader>
<imagetype>
<class>crystalspace.graphic.image.io.png</class>
<identify>
<mimetype>image/png</mimetype>
<extension>png</extension>
<extension>PNG</extension>
<scan length="4" bytes="\0x89PNG"/>
</identify>
</imagetype>
</imageloader>
</plugin>
In this example, the PNG loader meta-information tells the multiplexor
several different ways to identify a PNG image: by checking file
extension, if available; by checking MIME type, if available; by
checking for the magic-string "\0x89PNG" in the raw image data. If
the multiplexor identifies the image as PNG, only then will it
actually request the PNG loader.
-*- Added the --meta-file directive to msvcgen.pl to allow specification
of the meta-information file for a module. The value of this option
is interpolated into template files via the new %metafile% variable.
msvcgen.mak now utilizes this flag with the value of the new
INC.PROJECT makefile variable. Augmented the MSVC6 and MSVC7 plugin
template files (plugin.tpl) to make use of %metafile%.
-*- Changed the file extension for plugins on MacOS/X from .csplugin to
.csbundle to avoid conflict with new meta-information resource which
uses the extension .csplugin.
-*- Still To-Do:
- Augment SCF to utilize the new meta-information resources, and to
understand the new XML format. Presently, these resources are
ignored at run-time.
- Add platform-specific function to scan and locate plugins
automatically, rather than relying upon a monolithic registry such
as scf.cfg.
- Add platform-specific function to query a plugin's meta-information.
- Eliminate the monolithic scf.cfg.
- Augment static linking to work with the new facility.
- Eliminate the hard-coded SCF registration information in each
plugin's source code.
3 lines of code changed in:
Eric Sunshine changed the makefile-based build on MacOS/X so that plugins
are no longer placed in a "components" subdirectory. Although this was an
organizational convenience, it was not necessary, and it did not fit in
well with the LFS organization for installed resources toward which CS is
moving. This change should allow the plugins to be located when built and
installed via the Jam build facility, which uses an LFS organization.
30 lines of code changed in:
Eric Sunshine made the following changes:
-*- Modified configure.ac so that it emits a SRCDIR property to
config.mak. This value represents the --srcdir argument given to the
configure script (or "." if --srcdir is omitted). This points at the
directory containing the CS source code (which may differ from the
build directory, which is typically the current working directory).
-*- Modified makefiles and build scripts throughout the project so that
they respect $(SRCDIR). This allows the project to be built in a
directory other than the source directory, thus it is possible to
place the source directory on a readonly filesystem (such as a
CD-ROM), or to share a single NFS-mounted source directory among
different builds, where each build inhabits its own directory. For
example, if CS resides at /home/CS and you wish to build the project
in /home/build:
% cd /home/build
% ../CS/configure
% make -k all
% make install
(Note that the Jam-base build system already supports this build
paradigm.)
-*- Modified configure.ac so that it emits EXTENSIVE_MEMDEBUG to
config.mak since this variable is used by Makefile.in for the
`showconfig' target.
-*- Modified configure.ac so that it emits MONITOR_MAKEFILE_CACHE when the
value is either "yes" or "no", instead of emitting it only when the
value is "yes". This was necessary because CS/mk/cache.mak prints the
value of this variable as part of $(SYSMODIFIER).
15 lines of code changed in:
removed unneccesary and strange files which have been a leftover from teh converter script
0 lines of code changed in:
(19 more)
Generated by StatCvs v0.2-dev