--- Don Mastrovito
<[EMAIL PROTECTED]> wrote:
> Rhys,
>
> I think I understand your problem, but it was a
> little hard to follow. You
> keep mentioning BC++, but that is a very different
> product from
> BCB. However, your path statement contains
> references to CBuilder and you
> are trying to use the BCB5 stuff, so I'll assume you
> are really running
> BCB5. Also path includes names like XML4C. Are you
> really trying to build
> XML4C or Xerces. They are similar, but I'm not
> familiar with the build
> requirements for XML4C. I rather doubt that the
> Xerces project files will
> work with with XML4C. I'll assume you really want
> to build Xerces.
>
> Your path statement is pretty ugly. Lots of
> programs have problems with
> exceedingly long path statements. There are even
> limits on the length
> imposed by a DOS box. In addition, there are a
> number of command line
> utilities that do not function properly if directory
> or file names include
> dashes ("-"). Command line utilities like BCC32,
> TLINK32, and ILINK32 do
> not always tolerate dashes in directory or file
> names because they look
> like switches. This is especially true for pre-BCB6
> compilers and
> linkers. Even then, BCB6 ILINK32 still has one such
> bug where an offensive
> path is contained within an environmental variable.
> Things like
> xml4c-src4_0_0 should be renamed. If possible,
> reset your path to what
> would have normally been there before you added the
> Xerces paths. Try this
> (carriage returns added for clarity):
>
> C:\WINDOWS;
> C:\WINDOWS\COMMAND;
> C:\jdk1.3.0_02\bin;
> C:\PROGRA~1\ULTRAE~1;
> C:\PROGRA~1\BORLAND\CBUILD~1\BIN;
> C:\PROGRA~1\BORLAND\CBUILD~1\PROJECTS\BPL
>
> The BCB5 version of XercesLib.bpr (the project file)
> will correctly build
> Xerces 1.6.0 provided the directory structure used
> by the CVS build tree is
> not altered. Open XercesLib.bpr in the IDE. Go to
> your project options
> and click on the "Directory/Includes" tab. Observe
> the Include
> paths. Note that they are all defined as relative
> paths with respect to
> the project directory. You will find the same is
> true for the library
> paths. This means there is no need to modify the
> system path to include
> any additional directories. Due to a buggy project
> manager, it is wise not
> to modify Xerces project options from within the
> IDE. The pre-BCB6 PM has
> problems with very large projects. Close (cancel)
> the options box, select
> "Project|Build" and you should end up with a usable
> DLL.
>
> The workaround you mention has to do with path
> modifications within the
> project environment itself and not those referenced
> externally (such as the
> system path). It only applies to version BCB6.
>
> I would also suggest you stick with Xerces 1.6.0 if
> you have BCB5. The
> older stuff had a number of problems (getting it to
> build and in using it)
> and I have no plans to update the project file to
> work with 1.7.0.
>
> HTH,
> Don
Dear Don,
I am definitely using BCB5, having purchased BCB5
professional from my college bookstore a few months
back. I went back and downloaded both the source and
binary distributions for 1.6.0 . I was, indeed,
trying to work with XML4C and Xerces at the same time,
and was apparently getting some of the documentation
mixed up.
I knew that my path was a nightmare, and subsequently
truncated it to what you suggested. My present path
is listed below (carriage returns for clarity):
C:\WINDOWS;
C:\WINDOWS\COMMAND;
C:\jdk1.3.0_02\bin;
C:\PROGRA~1\ULTRAE~1;
C:\PROGRA~1\BORLAND\CBUILD~1\BIN;
C:\PROGRA~\BORLAND\CBUILD~\PROJECTS\BPL;
C:\xerces\xercesC1_6_0win32\bin;
C:\xerces\xercesC1_6_0win32\include;
However, it seems that BCB5 is not checking in the
last two listed directories. I looked under the
project|options|Directories/Conditionals tab, and
noticed that the "Include Path" was set to:
$(BCB)\include;$(BCB)\include\vcl, the "Library Path"
was set to: $(BCB)\lib\obj;$(BCB)\lib, and the "Debug
Source Path" was set to: $(BCB)\source\vcl . In
testing whether I could include the Xerces classes in
with my own program, below, I noticed that the Xerces
classes could not be found while the std classes
could. In other words, I could use everything but
Xerces in my program (at least everything included
with BCB5 compiler). Listed below is my test program,
testXML.cpp .
// testXML.cpp
#include <iostream>
using std::cin;
using std::cout;
using std::endl;
#include "moncls.h"
#include "mydate.h"
#include "receipt.h"
#include <dom/DOM.hpp>
int main()
{
// code snippet #'s 1 and 2, gestalted
DOM_Document myDocument;
DOM_Node aNode =
myDocument.createElement("receipt");
DOM_Node docRootNode =
myDocument.getDocumentElement();
docRootNode.AppendChild(aNode);
return 0;
}
// end testXML.cpp
Upon compiling the previous code, I received the
following error messages:
errors:
[C++ Error] testXML.cpp(11): E2209 Unable to open
include file 'dom/DOM.hpp'
[C++ Error] testXML.cpp(16): E2451 Undefined symbol
'DOM_Document'
[C++ Error] testXML.cpp(16): E2379 Statement missing ;
[C++ Error] testXML.cpp(17): E2451 Undefined symbol
'DOM_Node'
[C++ Error] testXML.cpp(17): E2379 Statement missing ;
[C++ Error] testXML.cpp(18): E2379 Statement missing ;
[C++ Error] testXML.cpp(19): E2451 Undefined symbol
'docRootNode'
[C++ Error] testXML.cpp(19): E2451 Undefined symbol
'aNode'
Noticing the settings in the compiler which I
mentioned before, I moved the entire contents of the
Xerces binary distribution "includes" directory to the
BCB5 "Includes" directory listed in the compiler
settings. After doing this, I tried compiling
testXML.cpp , again, and received only a message about
AppendChild not being part of some class or other
(meaning of course that it had successfully found
DOM.hpp). This workaround seems to have solved my
includes problem, after a fashion.
I suppose that this is the part where I get the
slightest bit "greedy" and ask if there isn't any
other way to get the damned thing to work. I ask this
because I am aware that my workaround is probably not
necessary, provided I am doing it correctly, and I
would very much like to know how to do it correctly.
Particularly, I would like to avoid duplicating
storage space in the future when I need to use another
additional library in my programs.
I would assume that there is still something wrong
with my path, which is why I included the new one in
this message. I doubt that there is a problem with my
test program code, as such, but acknowledge that I am
fallible, so also have included that, as well as the
error messages attempting to compile it invokes.
Any thoughts or suggestions?
Still Confuzzled,
~Rhys Black
__________________________________________________
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!
http://mail.yahoo.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
