Borland C++ Builder project file and make file for the
command line compiler to build expat.dll
Unzip the patch from the directory above expat, then
read the README.borland file for instructions.
Logged In: YES
Does this need to be updated to reflect the header name change from
"config.h" to "expat_config.h"?
I don't think I'll have time to look at
this before 1.95.3; is this just a few additional files or do other files need
changing? I'll try to install the recent C++ Builder demo to try this out.
Well, I won't be able to install the C++ Builder demo on my Win2K
system since I don't have enough space on my system disk. ;-(
Closing due to non-responsiveness of the reporter and
generally not being able to bring this up to date.
Logged In: YES
Ahh, I didnt clue in that you wanted me to do something
previously. I have been keeping my proj and makefiles up
to date and have attached the latest. They should go into
expat/proj/win32/BCB5 (I did this instead of spreading
them around the directory tree to reduce clutter).
You can test it with the free Borland command line
compiler, the make files work with that.
If you are getting close to a release and want to include this
I'll check it out on a daily basis. Im using the cvs files.
Latest Borland Files
Re-opened and assigned to myself.
After a quick review:
I'd like to rename the "cleanall" target to simply "clean",
as this is a more common name for this function.
There appear to be many intermediate directories between the
top of the tree and the BCB5 directory; can this be reduced?
I'm also not sure if the expected structure is that
resulting from the installed version of the sources or just
the CVS checkout; it's largely the same, but slightly
different at the top (probably not in any relevant way). It
appears slightly tedious to make this work easily in both
tree structures, since the win32/ directory is not part of
the Source/ directory of the installed Expat package.
I still haven't had time to re-install my Windows
environment, so I can't yet install Borland's free
command-line compiler, so I'll need your guidance. ;-(
We are getting ready to release Expat 1.95.4 this coming Friday.
Marking this report "pending", awaiting your response.
The directory structure I used for the project files is copied
from easysoap and xerces-c. It is more than expat needs
at this point but if you start getting more and more ports to
other OS's and build tools it becomes necessary. For
example, your VC files could go into expat/proj/win32/VC6.
However, if you like, I can put everything into a directory
called BCB5 right under the expat root.
cleanall removes the executables, obj files and the build
directories. Instead of renaming it, I'll just create another
target called clean that only removes the obj files. I think
this is more standard. OK?
About the directory structure: I was assuming the cvs is
the same as the release structure. My build files are now
set up to put the binaries in "release" directories under the
various source directories (lib, examples, xmlwf and
gennmtab). Are you saying the installed directory structure
has all the source directories under src (or Source)? Also,
for the release, should all the binaries go into expat/win32?
I can do this no problem, just let me know.
I got the setup Im using now by translating the VC project
files into BCB format, so I figured it would be right, but I
never thought the installed structure would be different
from the cvs.
Regarding the clean and cleanall targets: You're right, the
new version of clean you describe would be better, and
"cleanall" should probably be named "distclean", and should
remove everything created in the process of running the
makefile (including DLLs, .LIB files, etc.).
The MSVC project works because the directories it needs are
all arranged the same way for both CVS checkouts and the
"installed" sources. You might want to look at
win32/MANIFEST.txt; it describes the layout of the installed
package on Windows. There is no equivalent of the win32
directory in the result; I'd imagined putting the BCB5
directory inside that. I think I could copy the directory
to Sources\BCB5 using the installer, but that makes it one
level closer to the top of the source tree in the installed
version than in CVS, which breaks the use of ..\.. references.
I like the idea of keeping the project files away from the
actual sources though. Perhaps I can change the MSVC
projects to work in a similar way, but I'm hesitant to make
so many changes to the structure just before tomorrow's release.
(Karl, any thoughts on moving the .DSP and .DSW files to
Would it be reasonable to adjust the files to work from
win32\bcb5, and only worry about them from CVS for now,
leaving them out of the installer in 1.95.4. Re-working the
project file layout can be done for 1.95.5, so it can be
given more thought.
Logged In: YES
> (Karl, any thoughts on moving the .DSP and .DSW
> files to win32\msvc6 ?)
Well, ideally I would like it symmetrical, i.e. all
the build files for the various targets should be
in separate directories on the same level.
It seems it is not that clear that we should have an extra
level for the OS, since Windows Dlls can be built on
VC6, BCB5 and Cygwin.
Also, the Make stuff may apply to various OSes
simultaneously. So, maybe we could have the Make stuff
at the top level, as we already have, and create one
child directory for each build target that needs special
treatment beyond Make. In other words, I am
thinking off a VC6 directory and a BCB5 directory directly
under the top level (I believe you already have a vms
directory like that).
Why dont I put the BCB files in expat/BCB5. Then the
make files will be there ready to by integrated into the top
level make files at a later date. Also, the VC proj's put the
binaries in various "release" directories but since the BCB
files are all in one place why dont I just put the binaries in
expat/win32/release. Finally, should I copy the libs to
expat/Lib? I can do all this today if you want to include it in
I am wondering if each build target should not have its
own "release" type directoy? Imagine you want to
maintain separate builds of Expat under VC6 and BCB5.
In that case it would be nice if they would not overwrite
each other. But maybe that is too fancy.
Karl: I like the idea that multiple toolchains can be
supported in one tree, but doubt it's worth the effort or
resulting fragility. Many tools aren't terribly flexible
about project layout, either. ;-(
Patrick: Let's create bcb5 at the top level today, and
place all the project-related files there. If the output
can go in bcb5\release, that should make it easy enough for
people to work with both Windows compilers in one tree for
now, and we can re-work things in the next release if that
seems to be the right thing.
I can add this as soon as I have a set of files you approve
of. I'm deleting the older of the packages you provided
since that's so out of date at this point.
The version Patrick sent to me in email, based on the
discussion in the comments on this report, has been checked
in for inclusion in Expat 1.95.4.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.