Total Lines Of Code: 205 (2003-07-11 20:29)
Summary Period: 1999-12-12 to 2003-06-22
[root]/CS/plugins/video/canvas/openglx/glide
Total Lines Of Code:
205 (2003-07-11 20:29)
| Author | Changes | Lines of code | Lines per change |
|---|---|---|---|
| Totals | 45 (100.0%) | 335 (100.0%) | 7.4 |
| norman | 7 (15.6%) | 196 (58.5%) | 28.0 |
| sunshine | 20 (44.4%) | 83 (24.8%) | 4.1 |
| andyz | 4 (8.9%) | 15 (4.5%) | 3.7 |
| matzebraun | 1 (2.2%) | 13 (3.9%) | 13.0 |
| jorrit | 9 (20.0%) | 13 (3.9%) | 1.4 |
| ghaussmann | 2 (4.4%) | 11 (3.3%) | 5.5 |
| ab031ns | 1 (2.2%) | 3 (0.9%) | 3.0 |
| philwyett | 1 (2.2%) | 1 (0.3%) | 1.0 |
Eric Sunshine removed the unused, obsolete, and deprecated top-level <name>
node from the .csplugin files.
0 lines of code changed in:
Eric Sunshine performed Phase Three of the elimination of the monolithic
scf.cfg:
-*- Eliminated the SCF information which was hardcoded in the .cpp files
of plugin modules, and which duplicated information in the external
.csplugin files.
-*- Plugin modules no longer maintain and export a monolithic class list.
Now, each factory implemented by the code is exported automatically.
-*- Added a new <implementation> child node to the <class> node in
.csplugin files. The value of this node is the name of the C++ class
which implements the SCF class. For instance, C++ class csVFS
implements crystalspace.kernel.vfs.
-*- Eliminated the following SCF macros which were related to exporting
SCF information from .cpp code and/or registering classes manually:
SCF_EXPORT_CLASS_TABLE
SCF_EXPORT_CLASS
SCF_EXPORT_CLASS_DEP
SCF_EXPORT_CLASS_TABLE_END
SCF_REGISTER_STATIC_CLASS_DEP
-*- Eliminated the following methods from iSCF:
RegisterStaticClass
RegisterClassList
-*- Plugin modules are now initialized/shutdown lazily as classes are
requested from them. The first time a class is requested, the plugin
is initialized. The plugin is shutdown after the last class instance
has been destroyed.
-*- Fixed bug in scf.h where SCF_PRINT_CALL_ADDRESS was not being enabled
for gcc 3.x.
-*- Fixed bug in win32.jam where GenerateExportDefs rule failed to ensure
that directory containing output file existed before creating file.
Also fixed bug where it failed to set up a dependency between the
input and output files.
-*- Still To-Do:
- Remove references to scf.cfg and scfreg from documentation. Also
document new .csplugin resources.
- Add platform-specific function to scan and locate plugins
automatically rather than using the ad-hoc approach inherited from
scanning for .scf files.
- Add platform-specific function to query a plugin's meta-information.
This should be used by SCF to do the raw extraction. Provide and
finalize API for higher-level clients to access meta-information.
- Augment static linking to work with the new facility. (Removal of
the hardcoded SCF information, has now broken static linking. It
worked until this time, even with all of the preceding changes.)
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.
15 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).
3 lines of code changed in:
added the Jamfiles
13 lines of code changed in:
Renamed/corrected header defines to CS coding-style.
3 lines of code changed in:
Eric Sunshine (hopefully) worked around a problem caused by buggy stat()
on Win9x and WinME where a bogus result is returned if the path has a
trailing slash. This causes problems with the makefile dependency rules
which depend upon $(OUTBASE), $(OUTOS), $(OUTPROC), or $(OUT), all of
which end with a slash, since make thinks that those directories don't
exist even when they are present. Consequently, make tries invoking
$(MKDIR) on already-present directories. The work-around was to redefine
these variable so without the trailing slash. Also updated all makefiles
throughout the project to take into account that these variables are no
longer defined with a trailing slash.
7 lines of code changed in:
Slight code cleanup: removed all trailing spaces and tabs from
all lines in all source and make files throughout the entire project.
Note that this will most likely not result in a significant
FPS increase :-)
4 lines of code changed in:
- Removed iSystem::GetObjectRegistry().
- The object registry is now a parameter to the system driver and
is no longer created by the system driver itself. Instead
csInitializer::CreateObjectRegistry() will now create the object
registry.
- Moved the cleanup of the object registry to
csInitializer::DestroyApplication(). Also moved the cleanup of
SCF to there.
- Added Clear() to the iObjectRegistry interface.
- Several system drivers performed some special code right before
NextFrame() was being handled (Win32, BeOS, ...). This special
code has now moved to an event handler in the system driver instead.
The system driver will now listen to cscmdPreProcess and perform
the functionality that used to be in NextFrame().
- Removed NextFrame() from iSystem, csSystemDriver and all subclasses
of csSystemDriver (SysSystemDriver for all platforms). In case
you needed to explicitely call this function (in CS only CSWS did
this) then you can call iVirtualClock::Advance() followed by
iEventQueue::Process().
- csApp now calls Advance()/Process().
- The result of this is that the iSystem interface has become empty.
So it can finally be removed!!! In addition CS_GET_SYSTEM is now
also gone.
- Moved the virtual clock implementation in the system driver to
a seperate csVirtualClock in csutil. The system driver no longer
creates and manages the virtual clock. The already existing
csInitializer::CreateVirtualClock() will now create and register
the virtual clock.
0 lines of code changed in:
Split iPlugin interface into iComponent and iEventHandler and
removed iPlugin interface. iComponent now contains the Initialize()
function and iEventHandler contains HandleEvent. The idea is
that event handling is a seperate concept from plugins so
HandleEvent does not belong in iPlugin. In addition the notion
of initializing is not plugin specific either so it also doesn't
belong to iPlugin. This means there is actually nothing left
in iPlugin so it is removed :-)
To change code to work with this you basically have to replace
iPlugin with iComponent. If you also need events (i.e. you used
HandleEvent) then you have to additionally create a new
embedded iEventHandler interface object.
4 lines of code changed in:
- Removed almost all usage of iSystem in the entire CS system. Instead
a pointer to the object registry (iObjectRegistry) is used. This
includes the following:
- iPlugin::Initialize().
- csConfigAccess class.
- csInitializeApplication().
- Constructor of csApp.
- Various others...
- Because iSystem is still needed in some cases (still busy with the
removal of that) there are some cases where you need to have a
pointer to the system. To get that pointer you can now use the
new CS_GET_SYSTEM define like this:
iSystem* sys = CS_GET_SYSTEM (object_reg);
Note that this define will go away as soon as iSystem is removed.
So it is only a temporary measure. CS_GET_SYSTEM is implemented
by asking the object registry where iSystem is now registered.
The use of iSystem is still required for using everything related
to events (this includes the iEventOutlet pointers and also the
elapsed time (GetElapsedTime()), GetMouseButton(), GetKeyState(),
Sleep(), NextFrame(), ...).
- For Python scripts this also means that the 'system' variable is
gone and has been replaced with 'object_reg'.
- Since they were not used I removed iSystem::Initialize(),
Loop(), Open(), and Close(). The csSystemDriver versions of these
functions are not removed though. They are still needed at this
moment.
2 lines of code changed in:
Eric Sunshine removed a bunch of Glide references from documentation,
sources, headers, and makefiles.
1 lines of code changed in:
Changed the following:
csPlugIn -> csPlugin
iPlugIn -> iPlugin
scfiPlugIn -> scfiPlugin
This change is a change of PlugIn for Plugin in
all instances inside the libs, plugins and apps.
This makes code read better and saves you a
SHIFT key every so often - Don't say we don't
think of your tired fingers. :-)
Work in progress...Hope will be finished today...
1 lines of code changed in:
Eric Sunshine made the following name changes throughout the project in
order to avoid global namespace pollution:
All SCF macros are now prefixed by "SCF_".
All MSG_BLAH macros are now prefixed by "CS_".
All QUERY_PLUGIN macros are now prefixed by "CS_".
All LOAD_PLUGIN macros are now prefixed by "CS_".
All IS_BLAH_EVENT macros are now prefixed by "CS_".
10 lines of code changed in:
Eric Sunshine renamed all of the pure SCF interface header files.
Considering that that these files were recently organized into well-named
subdirectories, it is possible to use more descriptive names for the files
themselves. Also dropped the `i' prefix.
Here are just a few examples of the new more meaningful and descriptive
names:
iengine/idlight.h --> iengine/dynlight.h
iengine/imeshobj.h --> iengine/mesh.h
imesh/imeshobj.h --> imesh/object.h
imesh/mfire.h --> imesh/fire.h
imap/ildrplug.h --> imap/reader.h
imap/isvrplg.h --> imap/writer.h
isound/isnddrv.h --> isound/driver.h
isound/isndlstn.h --> isound/listener.h
ivideo/imater.h --> ivideo/material.h
2 lines of code changed in:
Eric Sunshine made the following changes to the project:
-*- Moved all of the pure SCF interface header files (the filenames
beginning with `i') into subdirectories of CS/include. They no longer
reside directly in CS/include. The new subdirectories within
CS/include are iengine, igame, igeom, igraphic, imap, imesh, inetwork,
iobject, isound, isys, iterrain, iutil, ivaria, and ivideo. Also,
several files were decomposed into multiple new files, so you may need
to include one or more of the new files in place of the old ones. The
files which were specially split are:
itexture.h -> iengine/itexture.h & ivideo/itexture.h
imater.h -> iengine/imater.h & ivideo/imater.h
imeshobj.h -> iengine/imeshobj.h & imesh/imeshobj.h
iterrobj.h -> iengine/iterrobj.h & iterrain/iterrobj.h
Also updated all source & header files, documentation files, and
makefiles to reflect this change.
-*- Eliminated several compilation warnings throughout the project.
2 lines of code changed in:
Eric Sunshine made the following changes to the project:
-*- Resolved a circular reference problem between the system driver and
the VFS plugin. The actual problem was that the VFS plugin was
utilizing the new configuration manager module even though it should
not have been doing so. There are a couple of reasons why utilization
of the configuration manager by VFS was problematic. First, this
introduced an unwanted circularity since the configuration manager and
the VFS plugin each relied upon the services of the other. Second, it
does not make sense for the VFS plugin to utilize the configuration
manager at initialization time since the VFS plugin is loaded very
early in the application start-up sequence. In fact, it is loaded
before any other configuration files have been loaded (indeed, all
other configuration files are typically loaded from a VFS volume; thus
this was a chicken-and-egg issue). Now the VFS plugin manually loads
its own configuration file (vfs.cfg) rather than relying on the
configuration manager mechanism. In the future, we should introduce
some new API into the VFS plugin which allows an application to
override or augment the initial configuration from vfs.cfg. This will
allow a client application to provide its own VFS.Mount settings if
desired. Also note that when this API is finally added it should be
in the form of a method in the VFS plugin which is invoked by the
client application (or system driver) and that method should accept an
iConfigFile* as its argument. The VFS plugin can then query this
configuration object for the desired information. There is no need to
re-introduce any circularity with iConfigManager.
-*- Converted several modules to use the new configuration manager which
were missed by Martin when he made his conversion sweep through the
project.
-*- Modified all makefiles project-wide so that the individual `clean'
targets (such as `softclean', `x2dclean', etc.) no longer remove the
dependency information (.dep files). In theory, having a module's
`clean' target remove the .dep file was a sensible idea, however in
actual practice, it turned out to be quite obnoxious to lose
dependency information each time an individual module's `clean' target
was invoked. You can still remove dependency files by invoking one of
the standard and existing targets `cleandep' or `distclean'.
1 lines of code changed in:
Made the following changes to the project:
-*- Finally eliminated the evil monolithic apps/support/static.cpp file
which caused repeated maintenance headaches. The problem with this
file was that every time a plug-in module was added or removed from
the project, a developer also had to remember to edit static.cpp to
reflect the change. Thus, the perceived modularity of plug-ins was
offset by the very real monolithic disposition of this file.
-*- As a replacement for static.cpp, the new makefile CS/mk/static.mak
automatically and dynamically synthesizes C++ code which forces hard
symbolic references to each plug-in module being linked into the
application (assuming that the application is being linked
statically---that is, with USE_PLUGINS=no).
-*- Information used by the synthesis process is gleaned from the GNU
makefiles, project-wide. The old CFLAGS.STATIC_SCF makefile variable
has been removed. A new variable, SCF.STATIC, contains a list of
plug-in module basenames (such as `soft3d', `vfs', etc.), and this
information is used to synthesize the hard references needed when
linking applications statically.
-*- The static.mak makefile is smart enough to regenerate the synthesized
symbolic references when certain events occur; such as when the user
edits the list of plug-in modules in user.mak or reconfigures the
project's makefiles.
-*- Note that the new synthesis process is geared toward platforms which
utilize the GNU makefile system to build the project. It does not
apply to ports which use `project files'. However, historically, none
of the ports which rely on project files has ever supported static
linking, so this is no loss. If, in the future, a port does wish to
support static linking via project files, it would be a simple matter
to set up an automated synthesis task, and commit the result to the
CVS repository on a regular basis, much as is already done with MSVC
project files.
-*- Added $(DEP.EXE) to the dependency lists of the following GUI
applications. This should allow them to successfully link statically
(that is, when USE_PLUGINS is `no'):
cctest
g2dtest
-*- Removed $(DEP.EXE) from the dependency list of the following console
applications, since they need not link against the various plug-in
modules:
csfgen
makedep
scfreg
scftutor
textconv
uninst
1 lines of code changed in:
Corrected the long standing misnomer where USE_PLUGINS was incorrectly
specified as USE_SHARED_PLUGINS. Updated all makefiles, scripts, and
documentation to reflect this change.
1 lines of code changed in:
Eric Sunshine made the following changes to the project:
-*- Visual-C++ DSW and DSP project files are now automatically generated
and updated. Information gleaned from GNU makefiles, project-wide, is
used to synthesize DSW and DSP files on-the-fly. The project file
synthesis procedure attempts to enforce the invariant that if a module
builds correctly via the GNU makefile, then the same module should
build correctly via the Visual-C++ project file which was built from
information gleaned from the makefile. Thus, the headache associated
with manual maintenance of the Visual-C++ project files should be a
thing of the past.
-*- Added a new directory, CS/mk/msvcgen, in which all resources related
to automatic generation of Visual-C++ project files reside.
-*- Added msvcgen.pl, which is a Perl script capable of generating
Visual-C++ DSW and DSP files based upon input arguments and a set of
template files. The script accepts a useful array of options for
controlling several aspects of the synthesis process, and is also
independent of Crystal Space, thus it may be useful in other arenas as
well. A copious amount of documentation related to the generation of
DSW and DSP files, including a description of the special variables
which may appear in template files, may be viewed by invoking
msvcgen.pl with the --help option.
-*- Added the directory CS/mk/msvcgen/template, which contains template
files used by msvcgen.pl during the synthesis of Visual-C++ DSW and
DSP project files. The master level templates are appgui.tpl,
appcon.tpl, group.tpl, library.tpl, and plugin.tpl, which represent
the five different types of DSP files which can be generated. These
templates are supplemented by the template-include files dspgroup.tpi
and dspfile.tpi, which combine to form resource groups within each
DSP. The master level template dsw.tpl is used for synthesizing DSW
files and is supplemented by dswgroup.tpi and dswdep.tpi, which
combine to form dependency groups within the DSW. Refer to the --help
output of msvcgen.pl for a description of the special variables which
may appear in each of the template files.
-*- Added msvcgen.mak, which is the Crystal Space-specific makefile
responsible for generating, and optionally installing, Visual-C++ DSW
and DSP project files. It performs this task by gleaning information
from GNU makefiles throughout the project and then invoking msvcgen.pl
with the appropriate arguments to synthesize each DSP file represented
by a makefile, as well as the master DSW file, csall.dsw. Also added
the supplemental makefiles win32.mak and required.mak. The first,
win32.mak, contains additional Windows-specific DSP targets (such as
grpall, grpplugins, libcswin32dll, etc.) which are not otherwise
represented by makefiles. The second, required.mak, supplements the
normal PLUGINS makefile variable with a list of modules for which DSP
files must be generated regardless of the platform which is performing
the project file generation procedure. This allows any platform (such
as Unix) to generate the complete set of Visual-C++ project files.
-*- Added two makefile targets which are specific to Visual-C++ project
file generation and installation.
o 'msvcgen' builds the entire set of DSW and DSP files represented by
the GNU makefiles, project-wide. The generated files are placed in
CS/out/mk/visualc.
o 'msvcinst' copies the DSW and DSP files from CS/out/mk/visualc to
their official location at CS/mk/visualc. Furthermore, this target
instructs the user as to exactly which CVS commands must be invoked
in order to properly commit the newly generated files to the CVS
repository. For instance, if a new plugin named "foo" is added and
an old library named "bar" is dropped, the 'msvcinst' target will
instruct the user to invoke the commands "cvs add -kb plgfoo.dsp",
"cvs remove libbar.dsp", and "cvs commit" in order to make the
changes permanent. The 'msvcinst' target automatically invokes the
'msvcgen' target, so the synthesis and installation procedures can
be performed as one operation.
-*- Added support for automated Visual-C++ DSW and DSP project file
generation to all of the GNU makefiles, project-wide. Project file
synthesis is performed by gleaning the values from some existing
makefile variables as well as some newly added ones. In the following
discussion, assume that "PROJECT" is the core name of the module
represented by a particular makefile.
In addition to the existing makefile variable SRC.PROJECT, the
following new general-purpose variables were added to support
Visual-C++ project file creation:
o INC.PROJECT -- Complements SRC.PROJECT, but lists header files
related to this project.
o DEP.PROJECT -- Although this variable already existed in some
makefiles, its meaning has been altered slightly. The value of this
variable is the list of projects (typically library projects) upon
which this module depends. Each item in this list is the core name
of some other module, such as "CSGEOM", "CSUTIL", or "CSSYS".
o LIB.PROJECT -- This variable now assumes the roll which DEP.PROJECT
used to play in some makefiles. It lists the libraries upon which
this module depends. The value of this variable is normally derived
automatically from DEP.PROJECT, but may be specified manually in
very special cases if necessary (though doing so is frowned upon).
If specified manually, each entry should be of the form
"$(PROJECT.LIB)".
o CFG.PROJECT -- List of configuration files related to this module.
Furthermore, the following new variables specifically control DSW and
DSP project file creation. These variables should only appear in
makefiles for which a corresponding DSP file should be generated.
o MSVC.DSP -- This is the master list of modules for which project
files should be generated. Entries must be *appended* to this list
with the "+=" operator. Each entry is the core name of a module as
used within its makefile. For example, soft3d.mak, ensures that a
project file is created for the 3D software renderer by invoking
"MSVC.DSP += SOFT3D".
o DSP.PROJECT.NAME -- Base name (such as "soft3d") for the generated
project and target. This name is used to compose the DSP file name,
the end target (such as "soft3d.dll"), and the displayed project
name in the Visual-C++ IDE. In general, it should be identical to
the base name of the target which is generated for non-Windows
platforms.
o DSP.PROJECT.TYPE -- The module's type. It should be one of
"appgui", "appcon", "library", "plugin", or "group", which stand for
GUI application, console application, static library, plug-in
module, and pseudo-dependency group, respectively.
o DSP.PROJECT.RESOURCES -- Lists any extra human-readable resources
related to this module which are not covered by CFG.PROJECT. These
resources may be browsed in the Visual-C++ IDE as a convenience to
the user. Some good candidates, among others, for this variable are
files having the suffixes .inc, .y (yacc), .l (lex), and .txt.
o DSP.PROJECT.DEPEND -- Lists extra dependencies for this module.
Entries in this list have the same format as those in the
DEP.PROJECT list. This variable is generally only used for
pseudo-dependency group projects (see win32.mak).
-*- Renamed docproc.pl to jobber.pl and modified it to also rebuild and
commit Visual-C++ DSW and DSP project files in addition to its normal
duties of rebuilding and publishing project documentation. The script
is automatically invoked twice daily. As always, the script is smart
enough to add new project files, and remove obsolete project files
from the CVS repository in addition to committing those which were
only modified. It also takes special are to use the "-kb" option when
adding Visual-C++ project files to the repository in order to preserve
the CRLF line terminators (which Microsoft requires). Also, when
scanning directories to determine which files to add and remove from
the repository, ".cvsignore" files are now ignored (along with all
other CVS administrative files which have always been ignored).
-*- Performed significant unification and clean-up of makefiles throughout
the project. Simplified several makefiles which had unnecessarily
complicated innards. Also added missing makefiles: snda3d.mak,
sndds3d.mak.
-*- Changed suffix of OpenGL extension-detection files from .cpp to .inc
since they are use as include-files rather than stand-alone sources.
Also performed much clean-up of these files.
-*- The standard system-dependent makefiles now define the additional
utility command definitions CD, PWD, and PERL (in addition to other
existing definitions such as RM, MV, CC, etc.). The default
definitions are specified in unix.mak and dos.mak.
-*- The makefile fragment common.mak now specially defines $" and $| if
they are not already defined. This allows recursive 'make'
invocations to use these variables with "echo" commands within targets
in exactly the same way as top-level makefile targets can do so.
-*- Fixed the makefile 'clean' targets of all library modules so that they
also remove the generated dependency (.dep) file. (Other makefiles
around the project had already been repaired in this manner.)
-*- Removed obsolete memory-debugger support from cssys.mak. Andrew had
removed the remainder of this cruft from the rest of the project on
2000/10/30 but missed cssys.mak.
-*- Added better documentation and more correct protection to ddg.h's
inclusion of cssysdef.h.
-*- Removed references to obsolete "null" sound driver from makefiles and
documentation.
16 lines of code changed in:
(14 more)
Generated by StatCvs v0.2-dev