xml-cppdom-devel — Developer list

Re: [xml-cppdom-devel] Building cppdom prefix problem

[Patrick H. <pa...@13...>]

Allen Bierbaum wrote:
> Patrick Hartling wrote:
>> Doug McCorkle wrote:
>>  =20
>>> Hello,
>>>      Currently, when building cppdom, headers and libs are installed =
=20
>>> in prefix even if the install target is not listed. This causes =20
>>> issues when trying to make cppdom accessible through MacPorts. In =20
>>> general this seems to be somewhat of a problem.
>>>    =20
> Doug:
>=20
> I am coming to this a little late, but what is the problem building=20
> inside MacPorts?  Is there a requirement that build happens separately =

> from install?

All packaging utilities that I know of separate building from installing.=

Watching MacPorts builds run, they definitely do this, though I don't kno=
w
if it is a strict requirement. I bet that it is, though.

> cppdom is definitely not designed to do that.  It has been designed to =

> follow a fairly common best practice of having one command that does a =

> complete build and install and does it every time (it is also=20
> recommended to have this run the testsuite, but we don't have that in=20
> there yet. :).

Where is this stated as being a best practice? I would think that nearly
every library in existence allows for separate build and install steps.
Those that don't are going to make packaging a pain. For example, when yo=
u
build an RPM to be installed in /usr, you don't actually want it to go in=
to
/usr during the packaging process. It has to go into a staging area (whic=
h
is something that MacPorts uses) wherein the actual package is created. S=
o,
there end up being two installation trees: the staging area using during
packaging and the final destination when the package is installed. If you=

look at the RPM spec file for CppDOM, you'll see a hack where cppdom.fpc
gets edited after running 'scons install' to change the staging area pref=
ix
to the final destination prefix.

> That way developers are *always* using the same build=20
> paths that are used by users and packages to install the tool and there=
=20
> are no special hoops to jump through to install or package the=20
> software.

Not everyone is a developer. Installing a package is a separate thing fro=
m
building it. Having a developer installation is one thing, but that
shouldn't interfere with users being able to build and install the softwa=
re.

> Just one magic button that will take you from source to=20
> happiness. I hadn't heard of this causing problems before, so I am=20
> interested in hearing more here.
>=20
> If you really need the build and install separated, you could do=20
> something like this:
>=20
> - Build
>    - call scons without a prefix setting
> - Install
>    - call scons with a prefix setting
>=20
> This will end up "installing" cppdom in the development directories on =

> the first call, but it should work for you.

I am just about positive that that process won't work because cppdom.fpc
gets generated as part of the build. If the prefix changes, it doesn't ge=
t
regenerated (which seems like a bug). This is something that I know I hav=
e
seen, and this exact usage is what I was alluding to earlier when I said
"running the build separately from the installation doesn't work well."

 -Patrick

>> That sounds like bad behavior in general. Software shouldn't be instal=
ling
>> itself unless told to do so.
>>
>> The CppDOM build is in pretty bad shape and hasn't ever been quite wha=
t I
>> would call ideal. The installation part has never really worked correc=
tly,
>> but I don't think I have seen this specific behavior. What I have seen=
 is
>> that running the build separately from the installation doesn't work w=
ell,
>> but the build certainly should support a two-step build+install proces=
s.
>> What version are you using?
>>
>>  =20
>>> I "fixed" the problem =20
>>> by adding guards in the scons files but that may not be the solution =
=20
>>> everyone is looking for. Thoughts?
>>>    =20
>> What are guards in this context?
>>
>>  -Patrick

--=20
Patrick L. Hartling                    | VP Engineering, Infiscape Corp.
PGP: http://tinyurl.com/2oum9          | http://www.infiscape.com/

Re: [xml-cppdom-devel] Building cppdom prefix problem

[Allen B. <al...@vr...>]

Patrick Hartling wrote:
> Doug McCorkle wrote:
>   
>> Hello,
>>      Currently, when building cppdom, headers and libs are installed  
>> in prefix even if the install target is not listed. This causes  
>> issues when trying to make cppdom accessible through MacPorts. In  
>> general this seems to be somewhat of a problem.
>>     
Doug:

I am coming to this a little late, but what is the problem building 
inside MacPorts?  Is there a requirement that build happens separately 
from install?

cppdom is definitely not designed to do that.  It has been designed to 
follow a fairly common best practice of having one command that does a 
complete build and install and does it every time (it is also 
recommended to have this run the testsuite, but we don't have that in 
there yet. :).  That way developers are *always* using the same build 
paths that are used by users and packages to install the tool and there 
are no special hoops to jump through to install or package the 
software.  Just one magic button that will take you from source to 
happiness. I hadn't heard of this causing problems before, so I am 
interested in hearing more here.

If you really need the build and install separated, you could do 
something like this:

- Build
   - call scons without a prefix setting
- Install
   - call scons with a prefix setting

This will end up "installing" cppdom in the development directories on 
the first call, but it should work for you.

-Allen

>
> That sounds like bad behavior in general. Software shouldn't be installing
> itself unless told to do so.
>
> The CppDOM build is in pretty bad shape and hasn't ever been quite what I
> would call ideal. The installation part has never really worked correctly,
> but I don't think I have seen this specific behavior. What I have seen is
> that running the build separately from the installation doesn't work well,
> but the build certainly should support a two-step build+install process.
> What version are you using?
>
>   
>> I "fixed" the problem  
>> by adding guards in the scons files but that may not be the solution  
>> everyone is looking for. Thoughts?
>>     
>
> What are guards in this context?
>
>  -Patrick
>
>
>   
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> ------------------------------------------------------------------------
>
> _______________________________________________
> Xml-cppdom-devel mailing list
> Xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xml-cppdom-devel
>   

Re: [xml-cppdom-devel] Building cppdom prefix problem

[Patrick H. <pa...@13...>]

Doug McCorkle wrote:
> On Feb 15, 2007, at 3:58 PM, Patrick Hartling wrote:
>=20
>> Doug McCorkle wrote:
>>> Hello,
>>>      Currently, when building cppdom, headers and libs are installed
>>> in prefix even if the install target is not listed. This causes
>>> issues when trying to make cppdom accessible through MacPorts. In
>>> general this seems to be somewhat of a problem.
>> That sounds like bad behavior in general. Software shouldn't be =20
>> installing
>> itself unless told to do so.
>>
>> The CppDOM build is in pretty bad shape and hasn't ever been quite =20
>> what I
>> would call ideal. The installation part has never really worked =20
>> correctly,
>> but I don't think I have seen this specific behavior. What I have =20
>> seen is
>> that running the build separately from the installation doesn't =20
>> work well,
>> but the build certainly should support a two-step build+install =20
>> process.
>> What version are you using?
>>
> 0.6.6 source I believe.

OK. I suspect that the current 0.7 code is broken similarly, but I haven'=
t
checked.

>>> I "fixed" the problem
>>> by adding guards in the scons files but that may not be the solution
>>> everyone is looking for. Thoughts?
>> What are guards in this context?
>=20
> if 'install' in COMMAND_LINE_TARGETS:

Yikes. I am surprised that the build behaves this way, and yet, I bet it'=
s
because of the "developer" installation aspect. I am pretty sure that the=

CppDOM build performs an installation after building so that developers
don't have to run the separate install step (such a burden!). Perhaps wha=
t
needs to happen is that the build needs to look at the prefix setting and=

only perform the automatic installation-after-build step if the prefix is=

the developer installation.

 -Patrick


--=20
Patrick L. Hartling                    | VP Engineering, Infiscape Corp.
PGP: http://tinyurl.com/2oum9          | http://www.infiscape.com/

Re: [xml-cppdom-devel] Building cppdom prefix problem

[Doug M. <mc...@ia...>]

On Feb 15, 2007, at 3:58 PM, Patrick Hartling wrote:

> Doug McCorkle wrote:
>> Hello,
>>      Currently, when building cppdom, headers and libs are installed
>> in prefix even if the install target is not listed. This causes
>> issues when trying to make cppdom accessible through MacPorts. In
>> general this seems to be somewhat of a problem.
>
> That sounds like bad behavior in general. Software shouldn't be  
> installing
> itself unless told to do so.
>
> The CppDOM build is in pretty bad shape and hasn't ever been quite  
> what I
> would call ideal. The installation part has never really worked  
> correctly,
> but I don't think I have seen this specific behavior. What I have  
> seen is
> that running the build separately from the installation doesn't  
> work well,
> but the build certainly should support a two-step build+install  
> process.
> What version are you using?
>
0.6.6 source I believe.

>> I "fixed" the problem
>> by adding guards in the scons files but that may not be the solution
>> everyone is looking for. Thoughts?
>
> What are guards in this context?

if 'install' in COMMAND_LINE_TARGETS:

Doug

Re: [xml-cppdom-devel] Building cppdom prefix problem

[Patrick H. <pa...@13...>]

Doug McCorkle wrote:
> Hello,
>      Currently, when building cppdom, headers and libs are installed =20
> in prefix even if the install target is not listed. This causes =20
> issues when trying to make cppdom accessible through MacPorts. In =20
> general this seems to be somewhat of a problem.

That sounds like bad behavior in general. Software shouldn't be installin=
g
itself unless told to do so.

The CppDOM build is in pretty bad shape and hasn't ever been quite what I=

would call ideal. The installation part has never really worked correctly=
,
but I don't think I have seen this specific behavior. What I have seen is=

that running the build separately from the installation doesn't work well=
,
but the build certainly should support a two-step build+install process.
What version are you using?

> I "fixed" the problem =20
> by adding guards in the scons files but that may not be the solution =20
> everyone is looking for. Thoughts?

What are guards in this context?

 -Patrick


--=20
Patrick L. Hartling                    | VP Engineering, Infiscape Corp.
PGP: http://tinyurl.com/2oum9          | http://www.infiscape.com/

[xml-cppdom-devel] Building cppdom prefix problem

[Doug M. <mc...@ia...>]

Hello,
     Currently, when building cppdom, headers and libs are installed  
in prefix even if the install target is not listed. This causes  
issues when trying to make cppdom accessible through MacPorts. In  
general this seems to be somewhat of a problem. I "fixed" the problem  
by adding guards in the scons files but that may not be the solution  
everyone is looking for. Thoughts?

Doug

[xml-cppdom-devel] VR Juggler on Ubuntu (was Re: Problems compiling xml-cppdom)

[Patrick H. <pa...@13...>]

[I am cc'ing the vrjuggler-info list on this message since it is more abo=
ut
VR Juggler than CppDOM.]

Kevin Godby wrote:
> Hello.
>=20
>> I have packages for CppDOM, GMTL, and flagpoll. I intend to make packa=
ges
>> for VR Juggler, PyGMTL, and PyJuggler, but they are not a high priorit=
y at
>> the moment. They will probably be available before the end of this mon=
th,
>> though. I put what I have so far here:
>>
>>    http://www.infiscape.com/~patrick/ubuntu/
>>
>> BTW, once you get to compiling VR Juggler, you'll want to use the 2.0.=
2
>> source (or the latest 2.1 source) as it contains a fix for using Autoc=
onf 2.60.
>=20
> I'll use the packages that you have available.  As to the version of
> VR Juggler, which do you recommend?  Is the 2.1 version relatively
> stable?

Yes. We're preparing for the 2.2 release, so it is pretty stable at this
point. Beyond that, it has been used as the basis for some large projects=

that we have done.

> Have you tried compiling either 2.0.2 or 2.1 on Ubuntu and
> does one compile more easily than the other?

I have built 2.1 (with all features enabled), but I haven't tried 2.0.2 y=
et.
It would be a quick thing for me to try, but it will have to wait until M=
onday.

 -Patrick


--=20
Patrick L. Hartling                    | VP Engineering, Infiscape Corp.
PGP: http://tinyurl.com/2oum9          | http://www.infiscape.com/

Re: [xml-cppdom-devel] Problems compiling xml-cppdom

[Kevin G. <go...@gm...>]

Hello.

> I have packages for CppDOM, GMTL, and flagpoll. I intend to make packages
> for VR Juggler, PyGMTL, and PyJuggler, but they are not a high priority at
> the moment. They will probably be available before the end of this month,
> though. I put what I have so far here:
>
>    http://www.infiscape.com/~patrick/ubuntu/
>
> BTW, once you get to compiling VR Juggler, you'll want to use the 2.0.2
> source (or the latest 2.1 source) as it contains a fix for using Autoconf 2.60.

I'll use the packages that you have available.  As to the version of
VR Juggler, which do you recommend?  Is the 2.1 version relatively
stable?  Have you tried compiling either 2.0.2 or 2.1 on Ubuntu and
does one compile more easily than the other?

Thanks!

--Kevin

Re: [xml-cppdom-devel] Problems compiling xml-cppdom

[Patrick H. <pa...@13...>]

Kevin Godby wrote:
> On 1/5/07, Patrick Hartling <pa...@13...> wrote:
>> Kevin Godby wrote:
>> > Hello.
>> >
>> > I'm having trouble compiling xml-cppdom (as a prerequisite for
>> > compiling VR Juggler).
>> >
>> > When I try to compile svn trunk, I get the following error:
>> >
>> > -----
>> > g++ -o build.linux/type-debug--arch-x64/cppdom/libcppdom-0_7_7.so -m=
64
>> > -shared build.linux/type-debug--arch-x64/cppdom/cppdom.os
>> > build.linux/type-debug--arch-x64/cppdom/xmlparser.os
>> > build.linux/type-debug--arch-x64/cppdom/xmltokenizer.os
>> > build.linux/type-debug--arch-x64/cppdom/ext/OptionRepository.os
>> > build.linux/type-debug--arch-x64/cppdom/SpiritParser.os -L/usr/lib
>> > /usr/bin/ld:
>> /usr/lib/gcc/i486-linux-gnu/4.1.2/64/libstdc++.a(functexcept.o):
>> > relocation R_X86_64_32 against `std::bad_typeid::~bad_typeid()' can
>> > not be used when making a shared object; recompile with -fPIC
>> > /usr/lib/gcc/i486-linux-gnu/4.1.2/64/libstdc++.a: could not read
>> > symbols: Bad value
>> > collect2: ld returned 1 exit status
>> > scons: ***
>> [build.linux/type-debug--arch-x64/cppdom/libcppdom-0_7_7.so] Error 1
>> > scons: building terminated because of errors.
>> > -----
>>
>> When it builds the object files, is -fPIC used? If not, you could add
>> it to
>> the CFLAGS in the SConstruct ... somewhere. I haven't used the CppDOM
>> trunk,
>> and its build is surprisingly unfamiliar to me. Perhaps someone else
>> knows
>> where that option could/should be added.
>>
>> I notice that you're building the Boost Spirit parser for CppDOM. I
>> may be
>> wrong, but I don't think that you want to do that. IIRC, it ended up
>> being
>> slower than CppDOM's current parser. Of course, the Spirit parser is
>> likely
>> to be much smarter and more robust, so perhaps the author could chime =
in
>> here about the best course...
>=20
> I re-ran scons as 'scons var_arch=3Dia32' to compile only the 32-bit
> version and it succeeded.

I'm glad to hear it. The lack of -fPIC is definitely a bug--either in SCo=
ns
or in the CppDOM build.

> (It will be running on a 32-bit system..
> but apparently the default is to build all architectures.)

For better or for worse, yes, that is the case.

> As to the Spirit parser, that must also be the default (as I didn't
> specify any other options than the architecture to scons).  I've
> attached a log file of the trunk build.

It's probably because you have Boost installed in /usr. The build
auto-detects whether it should try to use the Spirit parser based on whet=
her
Spirit is available. There should probably be an override to prevent that=
=2E

>> > When I try to compile the released 0.6.6, I get the following error:=

>> >
>> > -----
>> > g++ -o build.linux-i686/test/suite/runner -m32
>> > build.linux-i686/test/suite/runner.o
>> > build.linux-i686/test/suite/TestCases/ErrorTest.o
>> > build.linux-i686/test/suite/TestCases/NodeTest.o
>> > build.linux-i686/test/suite/TestCases/ParseTest.o
>> > build.linux-i686/test/suite/TestCases/PredTest.o
>> > build.linux-i686/test/suite/TestCases/OptionRepositoryTest.o
>> > build.linux-i686/test/suite/TestCases/SpiritTest.o -L/usr/lib
>> > -Lbuild.linux-i686/instlinks/lib -lcppdom -lcppunit -ldl -ldl -ldl
>> > build.linux-i686/test/suite/TestCases/OptionRepositoryTest.o: In
>> > function `testHelpers::dump_node(cppdom::Node&, int)':
>> > test/testHelpers.h:13: multiple definition of
>> > `testHelpers::dump_node(cppdom::Node&, int)'
>> > build.linux-i686/test/suite/TestCases/NodeTest.o:test/testHelpers.h:=
13:
>> > first defined here
>> > collect2: ld returned 1 exit status
>> > scons: *** [build.linux-i686/test/suite/runner] Error 1
>> > scons: building terminated because of errors.
>> > -----
>>
>> Don't tell the build where to find CppUnit. That way, the test suite w=
ill
>> not be compiled.
>>
>> As far as this error goes, I don't know why you would be seeing multip=
ly
>> defined symbols in this case. The dump_node() function is declared
>> inline.
>> Looking at the code, I don't see any reason why it shouldn't be
>> defined in a
>> .cpp file to get rid of the inline hack.

I looked into this a little more, and moving dump_node()'s implementation=

into a .cpp file is not as straightforward as I had hoped. :(

> It auto-detected the CppUnit libraries; I didn't tell it where to find
> them.  I've attached a log file of my attempt to build the 0.6.6
> release as well.

I'm not sure what to tell you about this. I haven't tried building 0.6.6
with CppUnit on Ubuntu, and I don't see anything obviously wrong in the c=
ode.

>> > I'm using Ubuntu Linux 6.10 (edgy).  Any advice?
>>
>> I made a 32-bit .deb package for Ubuntu 6.10, but it looks as though y=
ou
>> want 64-bit. If you want a 32-bit build, I can send you the package.
>=20
> I'm interested in the 32-bit .deb package if it's available.  I'd also
> be interested in any other .deb packages you might have for VR Juggler
> and its dependencies (CPP DOM and GTML, primarily---I think most the
> other prerequisites already have .deb packages in the Ubuntu
> repositories).

I have packages for CppDOM, GMTL, and flagpoll. I intend to make packages=

for VR Juggler, PyGMTL, and PyJuggler, but they are not a high priority a=
t
the moment. They will probably be available before the end of this month,=

though. I put what I have so far here:

   http://www.infiscape.com/~patrick/ubuntu/

BTW, once you get to compiling VR Juggler, you'll want to use the 2.0.2
source (or the latest 2.1 source) as it contains a fix for using Autoconf=
 2.60.

 -Patrick


--=20
Patrick L. Hartling                    | VP Engineering, Infiscape Corp.
PGP: http://tinyurl.com/2oum9          | http://www.infiscape.com/

Re: [xml-cppdom-devel] Problems compiling xml-cppdom

[Kevin G. <go...@gm...>]

On 1/5/07, Patrick Hartling <pa...@13...> wrote:
> Kevin Godby wrote:
> > Hello.
> >
> > I'm having trouble compiling xml-cppdom (as a prerequisite for
> > compiling VR Juggler).
> >
> > When I try to compile svn trunk, I get the following error:
> >
> > -----
> > g++ -o build.linux/type-debug--arch-x64/cppdom/libcppdom-0_7_7.so -m64
> > -shared build.linux/type-debug--arch-x64/cppdom/cppdom.os
> > build.linux/type-debug--arch-x64/cppdom/xmlparser.os
> > build.linux/type-debug--arch-x64/cppdom/xmltokenizer.os
> > build.linux/type-debug--arch-x64/cppdom/ext/OptionRepository.os
> > build.linux/type-debug--arch-x64/cppdom/SpiritParser.os -L/usr/lib
> > /usr/bin/ld: /usr/lib/gcc/i486-linux-gnu/4.1.2/64/libstdc++.a(functexcept.o):
> > relocation R_X86_64_32 against `std::bad_typeid::~bad_typeid()' can
> > not be used when making a shared object; recompile with -fPIC
> > /usr/lib/gcc/i486-linux-gnu/4.1.2/64/libstdc++.a: could not read
> > symbols: Bad value
> > collect2: ld returned 1 exit status
> > scons: *** [build.linux/type-debug--arch-x64/cppdom/libcppdom-0_7_7.so] Error 1
> > scons: building terminated because of errors.
> > -----
>
> When it builds the object files, is -fPIC used? If not, you could add it to
> the CFLAGS in the SConstruct ... somewhere. I haven't used the CppDOM trunk,
> and its build is surprisingly unfamiliar to me. Perhaps someone else knows
> where that option could/should be added.
>
> I notice that you're building the Boost Spirit parser for CppDOM. I may be
> wrong, but I don't think that you want to do that. IIRC, it ended up being
> slower than CppDOM's current parser. Of course, the Spirit parser is likely
> to be much smarter and more robust, so perhaps the author could chime in
> here about the best course...

I re-ran scons as 'scons var_arch=ia32' to compile only the 32-bit
version and it succeeded.  (It will be running on a 32-bit system..
but apparently the default is to build all architectures.)

As to the Spirit parser, that must also be the default (as I didn't
specify any other options than the architecture to scons).  I've
attached a log file of the trunk build.

> > When I try to compile the released 0.6.6, I get the following error:
> >
> > -----
> > g++ -o build.linux-i686/test/suite/runner -m32
> > build.linux-i686/test/suite/runner.o
> > build.linux-i686/test/suite/TestCases/ErrorTest.o
> > build.linux-i686/test/suite/TestCases/NodeTest.o
> > build.linux-i686/test/suite/TestCases/ParseTest.o
> > build.linux-i686/test/suite/TestCases/PredTest.o
> > build.linux-i686/test/suite/TestCases/OptionRepositoryTest.o
> > build.linux-i686/test/suite/TestCases/SpiritTest.o -L/usr/lib
> > -Lbuild.linux-i686/instlinks/lib -lcppdom -lcppunit -ldl -ldl -ldl
> > build.linux-i686/test/suite/TestCases/OptionRepositoryTest.o: In
> > function `testHelpers::dump_node(cppdom::Node&, int)':
> > test/testHelpers.h:13: multiple definition of
> > `testHelpers::dump_node(cppdom::Node&, int)'
> > build.linux-i686/test/suite/TestCases/NodeTest.o:test/testHelpers.h:13:
> > first defined here
> > collect2: ld returned 1 exit status
> > scons: *** [build.linux-i686/test/suite/runner] Error 1
> > scons: building terminated because of errors.
> > -----
>
> Don't tell the build where to find CppUnit. That way, the test suite will
> not be compiled.
>
> As far as this error goes, I don't know why you would be seeing multiply
> defined symbols in this case. The dump_node() function is declared inline.
> Looking at the code, I don't see any reason why it shouldn't be defined in a
> .cpp file to get rid of the inline hack.

It auto-detected the CppUnit libraries; I didn't tell it where to find
them.  I've attached a log file of my attempt to build the 0.6.6
release as well.

> > I'm using Ubuntu Linux 6.10 (edgy).  Any advice?
>
> I made a 32-bit .deb package for Ubuntu 6.10, but it looks as though you
> want 64-bit. If you want a 32-bit build, I can send you the package.

I'm interested in the 32-bit .deb package if it's available.  I'd also
be interested in any other .deb packages you might have for VR Juggler
and its dependencies (CPP DOM and GTML, primarily---I think most the
other prerequisites already have .deb packages in the Ubuntu
repositories).

Thanks again for your help!

--Kevin Godby

Re: [xml-cppdom-devel] Problems compiling xml-cppdom

[Patrick H. <pa...@13...>]

Kevin Godby wrote:
> Hello.
>=20
> I'm having trouble compiling xml-cppdom (as a prerequisite for
> compiling VR Juggler).
>=20
> When I try to compile svn trunk, I get the following error:
>=20
> -----
> g++ -o build.linux/type-debug--arch-x64/cppdom/libcppdom-0_7_7.so -m64
> -shared build.linux/type-debug--arch-x64/cppdom/cppdom.os
> build.linux/type-debug--arch-x64/cppdom/xmlparser.os
> build.linux/type-debug--arch-x64/cppdom/xmltokenizer.os
> build.linux/type-debug--arch-x64/cppdom/ext/OptionRepository.os
> build.linux/type-debug--arch-x64/cppdom/SpiritParser.os -L/usr/lib
> /usr/bin/ld: /usr/lib/gcc/i486-linux-gnu/4.1.2/64/libstdc++.a(functexce=
pt.o):
> relocation R_X86_64_32 against `std::bad_typeid::~bad_typeid()' can
> not be used when making a shared object; recompile with -fPIC
> /usr/lib/gcc/i486-linux-gnu/4.1.2/64/libstdc++.a: could not read
> symbols: Bad value
> collect2: ld returned 1 exit status
> scons: *** [build.linux/type-debug--arch-x64/cppdom/libcppdom-0_7_7.so]=
 Error 1
> scons: building terminated because of errors.
> -----

When it builds the object files, is -fPIC used? If not, you could add it =
to
the CFLAGS in the SConstruct ... somewhere. I haven't used the CppDOM tru=
nk,
and its build is surprisingly unfamiliar to me. Perhaps someone else know=
s
where that option could/should be added.

I notice that you're building the Boost Spirit parser for CppDOM. I may b=
e
wrong, but I don't think that you want to do that. IIRC, it ended up bein=
g
slower than CppDOM's current parser. Of course, the Spirit parser is like=
ly
to be much smarter and more robust, so perhaps the author could chime in
here about the best course...

> When I try to compile the released 0.6.6, I get the following error:
>=20
> -----
> g++ -o build.linux-i686/test/suite/runner -m32
> build.linux-i686/test/suite/runner.o
> build.linux-i686/test/suite/TestCases/ErrorTest.o
> build.linux-i686/test/suite/TestCases/NodeTest.o
> build.linux-i686/test/suite/TestCases/ParseTest.o
> build.linux-i686/test/suite/TestCases/PredTest.o
> build.linux-i686/test/suite/TestCases/OptionRepositoryTest.o
> build.linux-i686/test/suite/TestCases/SpiritTest.o -L/usr/lib
> -Lbuild.linux-i686/instlinks/lib -lcppdom -lcppunit -ldl -ldl -ldl
> build.linux-i686/test/suite/TestCases/OptionRepositoryTest.o: In
> function `testHelpers::dump_node(cppdom::Node&, int)':
> test/testHelpers.h:13: multiple definition of
> `testHelpers::dump_node(cppdom::Node&, int)'
> build.linux-i686/test/suite/TestCases/NodeTest.o:test/testHelpers.h:13:=

> first defined here
> collect2: ld returned 1 exit status
> scons: *** [build.linux-i686/test/suite/runner] Error 1
> scons: building terminated because of errors.
> -----

Don't tell the build where to find CppUnit. That way, the test suite will=

not be compiled.

As far as this error goes, I don't know why you would be seeing multiply
defined symbols in this case. The dump_node() function is declared inline=
=2E
Looking at the code, I don't see any reason why it shouldn't be defined i=
n a
=2Ecpp file to get rid of the inline hack.

> I'm using Ubuntu Linux 6.10 (edgy).  Any advice?

I made a 32-bit .deb package for Ubuntu 6.10, but it looks as though you
want 64-bit. If you want a 32-bit build, I can send you the package.

 -Patrick


--=20
Patrick L. Hartling                    | VP Engineering, Infiscape Corp.
PGP: http://tinyurl.com/2oum9          | http://www.infiscape.com/

[xml-cppdom-devel] Problems compiling xml-cppdom

[Kevin G. <go...@gm...>]

Hello.

I'm having trouble compiling xml-cppdom (as a prerequisite for
compiling VR Juggler).

When I try to compile svn trunk, I get the following error:

-----
g++ -o build.linux/type-debug--arch-x64/cppdom/libcppdom-0_7_7.so -m64
-shared build.linux/type-debug--arch-x64/cppdom/cppdom.os
build.linux/type-debug--arch-x64/cppdom/xmlparser.os
build.linux/type-debug--arch-x64/cppdom/xmltokenizer.os
build.linux/type-debug--arch-x64/cppdom/ext/OptionRepository.os
build.linux/type-debug--arch-x64/cppdom/SpiritParser.os -L/usr/lib
/usr/bin/ld: /usr/lib/gcc/i486-linux-gnu/4.1.2/64/libstdc++.a(functexcept.o):
relocation R_X86_64_32 against `std::bad_typeid::~bad_typeid()' can
not be used when making a shared object; recompile with -fPIC
/usr/lib/gcc/i486-linux-gnu/4.1.2/64/libstdc++.a: could not read
symbols: Bad value
collect2: ld returned 1 exit status
scons: *** [build.linux/type-debug--arch-x64/cppdom/libcppdom-0_7_7.so] Error 1
scons: building terminated because of errors.
-----

When I try to compile the released 0.6.6, I get the following error:

-----
g++ -o build.linux-i686/test/suite/runner -m32
build.linux-i686/test/suite/runner.o
build.linux-i686/test/suite/TestCases/ErrorTest.o
build.linux-i686/test/suite/TestCases/NodeTest.o
build.linux-i686/test/suite/TestCases/ParseTest.o
build.linux-i686/test/suite/TestCases/PredTest.o
build.linux-i686/test/suite/TestCases/OptionRepositoryTest.o
build.linux-i686/test/suite/TestCases/SpiritTest.o -L/usr/lib
-Lbuild.linux-i686/instlinks/lib -lcppdom -lcppunit -ldl -ldl -ldl
build.linux-i686/test/suite/TestCases/OptionRepositoryTest.o: In
function `testHelpers::dump_node(cppdom::Node&, int)':
test/testHelpers.h:13: multiple definition of
`testHelpers::dump_node(cppdom::Node&, int)'
build.linux-i686/test/suite/TestCases/NodeTest.o:test/testHelpers.h:13:
first defined here
collect2: ld returned 1 exit status
scons: *** [build.linux-i686/test/suite/runner] Error 1
scons: building terminated because of errors.
-----

I'm using Ubuntu Linux 6.10 (edgy).  Any advice?

Thanks!

--Kevin Godby

[xml-cppdom-devel] [ xml-cppdom-Support Requests-1619088 ] xml file properties

[SourceForge.net <no...@so...>]

Support Requests item #1619088, was opened at 2006-12-19 16:09
Message generated for change (Comment added) made by patrickh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=467782&aid=1619088&group_id=52718

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: aiscape (aiscape)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml file properties

Initial Comment:
Hi I'm a xml noob and want to try cppdom in a tiny project.

I want to read in xml files, modify it and write it out. Manipulating nodes works as expected but I have the problem that the input files have xml attribs like encoding or standalone and cppdom doesn't write out these properties while savin' the document.

Sample:

I read in the following xml, modify the stuff inside element 

<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<element>
bla bla
</element>

and get the following after writing the doc to file:

<?xml version="1.0" ?>
<?xml ?>
<element>
bla bla
</element>

After modifing the same file twice, I get:
<?xml version="1.0" ?>
<?xml ?>
<?xml ?>
<element>
bla bla
</element>

What's going on here. I'm sure I missed something. Please, can you help me out?

Thanks a lot for help and for developing cppdom. I like  it 'cause it is so small.

Cheers, Yves.

----------------------------------------------------------------------

>Comment By: Patrick Hartling (patrickh)
Date: 2006-12-20 10:55

Message:
Logged In: YES 
user_id=49856
Originator: NO

You aren't missing anything. This is a bug/shortcoming in how CppDOM
writes out XML files. Currently, it is hard-coded to write out only the XML
version. If you have a patch to address this problem, we would be happy to
review it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=467782&aid=1619088&group_id=52718

[xml-cppdom-devel] [ xml-cppdom-Support Requests-1619088 ] xml file properties

[SourceForge.net <no...@so...>]

Support Requests item #1619088, was opened at 2006-12-19 22:09
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=467782&aid=1619088&group_id=52718

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: aiscape (aiscape)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml file properties

Initial Comment:
Hi I'm a xml noob and want to try cppdom in a tiny project.

I want to read in xml files, modify it and write it out. Manipulating nodes works as expected but I have the problem that the input files have xml attribs like encoding or standalone and cppdom doesn't write out these properties while savin' the document.

Sample:

I read in the following xml, modify the stuff inside element 

<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<element>
bla bla
</element>

and get the following after writing the doc to file:

<?xml version="1.0" ?>
<?xml ?>
<element>
bla bla
</element>

After modifing the same file twice, I get:
<?xml version="1.0" ?>
<?xml ?>
<?xml ?>
<element>
bla bla
</element>

What's going on here. I'm sure I missed something. Please, can you help me out?

Thanks a lot for help and for developing cppdom. I like  it 'cause it is so small.

Cheers, Yves.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=467782&aid=1619088&group_id=52718

[xml-cppdom-devel] CppDOM 0.6.6 released

[Patrick H. <pa...@13...>]

Several builds of the CppDOM 0.6.6 release have just been posted on
SourceForge. The changes in this relate exclusively to non-Windows platfo=
rms:

   1. Fixed bad paths in cppdom-config as installed by the
      cppdom-devel RPM
   2. Added a Flagpoll .fpc file for CppDOM for use instead of
      cppdom-config (for more information about Flagpoll, see
      https://realityforge.vrsource.org/view/FlagPoll/WebHome)

No Windows builds have been made for this release since there are no chan=
ges
to the C++ source to cppdom/version.h.

 -Patrick


--=20
Patrick L. Hartling                    | VP Engineering, Infiscape Corp.
PGP: http://tinyurl.com/2oum9          | http://www.infiscape.com/

Re: [xml-cppdom-devel] [ggt-devel] Versioned directories on Windows

[subatomic <ke...@su...>]

>> Are there issues with two running apps accessing the same name of dll
(but in different folders)??

to clarify...  I was talking about 2 apps, accessing the same name dll from
different locations, each of which is a different version than the other...


On 9/27/06, subatomic <ke...@su...> wrote:
>
>
> totally agree...
> and, if you need to change names on anything, do it on the filename...
> i.e.
> cppdom-1.4.5.dll
> cppdomD-1.4.5.dll
>
> but keep it in the local directory...
> having these global stores (first the registry, now the dll database in
> windows) seems prone to errors, or if nothing else, really inconvenient and
> like you say, different than any other platform.
>
>
> Are there issues with two running apps accessing the same name of dll (but
> in different folders)??
> If so, you may want to do the naming thing I mentioned above...
> Otherwise, why add the complication....
>
> - kevin
>
> On 9/27/06, Allen Bierbaum <al...@vr...> wrote:
> >
> > Aron Bierbaum wrote:
> >
> > >I agree with you 100% on this. I think that introducing versioned
> > header
> > >directories on Windows is only going to further complicate things. I
> > >can't say that I know how a lot of packages handle this on Windows. But
> >
> > >I do know that Qt defaults to being installed in C:\Qt\4.1.4\. This
> > >sounds very similar to how we could handle it. C:\Program
> > >Files\gmtl\0.5.0  and C:\Program Files\cppdom\0.6.5
> > >
> > >-Aron
> > >
> > >
> > This sounds fine with me. Windows is an anomaly so lets just make it
> > easy on ourselves and use something that will work for what we need.
> >
> > -Allen
> >
> > >
> > >Patrick Hartling wrote:
> > >
> > >
> > >>Sorry for the cross posting, but this involves both CppDOM and GMTL. I
> > >>recently made the statements below on the vrjuggler-devel mailing list
> > and
> > >>have received no comments, criticisms, or feedback. This is an
> > important
> > >>issue that needs to be resolved, so here is what I said:
> > >>
> >
> > >>===========================================================================
> > >>
> > >>Versioned Header and Data Directories on Windows
> > >>------------------------------------------------
> > >>
> > >>Getting back to the parallel installation topic, Windows has been
> > updated to
> > >>created versioned DLLs and to generate .fpc files for building against
> > VR
> > >>Juggler from the command line (yes, that is finally supported again).
> > >>However, the header and data directories are not currently being
> > versioned
> > >>the way that they are on non-Windows platforms, and a decision needs
> > to be
> > >>made regarding whether it is necessary to do that.
> > >>
> > >>My vote on this topic is not to version the header or data directories
> > on
> > >>Windows. Deployment on Windows is fundamentally different than on
> > other
> > >>operating systems because there is no equivalent of /usr/include (or
> > >>/usr/local/include) or /usr/share (or /usr/local/share). Rather,
> > software
> > >>on Windows usually goes into C:\Program Files\<directory> where
> > <directory>
> > >>can be named with a version. This makes parallel installations easier
> > since
> > >>the files are separated at a higher level in the directory structure.
> > It
> > >>also makes it easier to handle Visual C++ project files since they
> > don't
> > >>have to be updated to track the name of the include directories (which
> > could
> > >>require a lot of work since there are would be one /I option needed
> > for each
> > >>Juggler module). Structuring things this way is what the Boost
> > Consulting's
> > >>slick installer for Boost on Windows does, and I would apply this same
> > >>argument to CppDOM and GMTL.
> > >>
> > >>===========================================================================
> >
> > >>
> > >>Thoughts?
> > >>
> > >> -Patrick
> > >>
> > >>
> > >>
> >
> > >>------------------------------------------------------------------------
> > >>
> > >>-------------------------------------------------------------------------
> >
> > >>Take Surveys. Earn Cash. Influence the Future of IT
> > >>Join SourceForge.net's Techsay panel and you'll get the chance to
> > share your
> > >>opinions on IT & business topics through brief surveys -- and earn
> > cash
> > >>
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > >>------------------------------------------------------------------------
> >
> > >>
> > >>_______________________________________________
> > >>Xml-cppdom-devel mailing list
> > >>Xml...@li...
> > >>https://lists.sourceforge.net/lists/listinfo/xml-cppdom-devel
> > >>
> > >>
> > >>
> > >
> > >
> > >-------------------------------------------------------------------------
> >
> > >Take Surveys. Earn Cash. Influence the Future of IT
> > >Join SourceForge.net's Techsay panel and you'll get the chance to share
> > your
> > >opinions on IT & business topics through brief surveys -- and earn cash
> >
> > >
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > >_______________________________________________
> > >Xml-cppdom-devel mailing list
> > >Xml...@li...
> > > https://lists.sourceforge.net/lists/listinfo/xml-cppdom-devel
> > >
> > >
> > >
> >
> >
> >
> > -------------------------------------------------------------------------
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the chance to share
> > your
> > opinions on IT & business topics through brief surveys -- and earn cash
> >
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> > _______________________________________________
> > ggt-devel mailing list
> > ggt...@li...
> > https://lists.sourceforge.net/lists/listinfo/ggt-devel
> >
>
>
>
> --
> Kevin Meinert
> http://www.subatomicglue.com




-- 
Kevin Meinert
http://www.subatomicglue.com

Re: [xml-cppdom-devel] [ggt-devel] Versioned directories on Windows

[subatomic <ke...@su...>]

totally agree...
and, if you need to change names on anything, do it on the filename...
i.e.
cppdom-1.4.5.dll
cppdomD-1.4.5.dll

but keep it in the local directory...
having these global stores (first the registry, now the dll database in
windows) seems prone to errors, or if nothing else, really inconvenient and
like you say, different than any other platform.


Are there issues with two running apps accessing the same name of dll (but
in different folders)??
If so, you may want to do the naming thing I mentioned above...
Otherwise, why add the complication....

- kevin

On 9/27/06, Allen Bierbaum <al...@vr...> wrote:
>
> Aron Bierbaum wrote:
>
> >I agree with you 100% on this. I think that introducing versioned header
> >directories on Windows is only going to further complicate things. I
> >can't say that I know how a lot of packages handle this on Windows. But
> >I do know that Qt defaults to being installed in C:\Qt\4.1.4\. This
> >sounds very similar to how we could handle it. C:\Program
> >Files\gmtl\0.5.0  and C:\Program Files\cppdom\0.6.5
> >
> >-Aron
> >
> >
> This sounds fine with me. Windows is an anomaly so lets just make it
> easy on ourselves and use something that will work for what we need.
>
> -Allen
>
> >
> >Patrick Hartling wrote:
> >
> >
> >>Sorry for the cross posting, but this involves both CppDOM and GMTL. I
> >>recently made the statements below on the vrjuggler-devel mailing list
> and
> >>have received no comments, criticisms, or feedback. This is an important
> >>issue that needs to be resolved, so here is what I said:
> >>
>
> >>===========================================================================
> >>
> >>Versioned Header and Data Directories on Windows
> >>------------------------------------------------
> >>
> >>Getting back to the parallel installation topic, Windows has been
> updated to
> >>created versioned DLLs and to generate .fpc files for building against
> VR
> >>Juggler from the command line (yes, that is finally supported again).
> >>However, the header and data directories are not currently being
> versioned
> >>the way that they are on non-Windows platforms, and a decision needs to
> be
> >>made regarding whether it is necessary to do that.
> >>
> >>My vote on this topic is not to version the header or data directories
> on
> >>Windows. Deployment on Windows is fundamentally different than on other
> >>operating systems because there is no equivalent of /usr/include (or
> >>/usr/local/include) or /usr/share (or /usr/local/share). Rather,
> software
> >>on Windows usually goes into C:\Program Files\<directory> where
> <directory>
> >>can be named with a version. This makes parallel installations easier
> since
> >>the files are separated at a higher level in the directory structure. It
> >>also makes it easier to handle Visual C++ project files since they don't
> >>have to be updated to track the name of the include directories (which
> could
> >>require a lot of work since there are would be one /I option needed for
> each
> >>Juggler module). Structuring things this way is what the Boost
> Consulting's
> >>slick installer for Boost on Windows does, and I would apply this same
> >>argument to CppDOM and GMTL.
> >>
>
> >>===========================================================================
> >>
> >>Thoughts?
> >>
> >> -Patrick
> >>
> >>
> >>
> >>------------------------------------------------------------------------
> >>
>
> >>-------------------------------------------------------------------------
> >>Take Surveys. Earn Cash. Influence the Future of IT
> >>Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> >>opinions on IT & business topics through brief surveys -- and earn cash
> >>
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> >>------------------------------------------------------------------------
> >>
> >>_______________________________________________
> >>Xml-cppdom-devel mailing list
> >>Xml...@li...
> >>https://lists.sourceforge.net/lists/listinfo/xml-cppdom-devel
> >>
> >>
> >>
> >
> >
> >-------------------------------------------------------------------------
> >Take Surveys. Earn Cash. Influence the Future of IT
> >Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> >opinions on IT & business topics through brief surveys -- and earn cash
> >http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> >_______________________________________________
> >Xml-cppdom-devel mailing list
> >Xml...@li...
> >https://lists.sourceforge.net/lists/listinfo/xml-cppdom-devel
> >
> >
> >
>
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share
> your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> ggt-devel mailing list
> ggt...@li...
> https://lists.sourceforge.net/lists/listinfo/ggt-devel
>



-- 
Kevin Meinert
http://www.subatomicglue.com

Re: [xml-cppdom-devel] Versioned directories on Windows

[Allen B. <al...@vr...>]

Aron Bierbaum wrote:

>I agree with you 100% on this. I think that introducing versioned header 
>directories on Windows is only going to further complicate things. I 
>can't say that I know how a lot of packages handle this on Windows. But 
>I do know that Qt defaults to being installed in C:\Qt\4.1.4\. This 
>sounds very similar to how we could handle it. C:\Program 
>Files\gmtl\0.5.0  and C:\Program Files\cppdom\0.6.5
>
>-Aron
>  
>
This sounds fine with me. Windows is an anomaly so lets just make it 
easy on ourselves and use something that will work for what we need.

-Allen

>
>Patrick Hartling wrote:
>  
>
>>Sorry for the cross posting, but this involves both CppDOM and GMTL. I
>>recently made the statements below on the vrjuggler-devel mailing list and
>>have received no comments, criticisms, or feedback. This is an important
>>issue that needs to be resolved, so here is what I said:
>>
>>===========================================================================
>>
>>Versioned Header and Data Directories on Windows
>>------------------------------------------------
>>
>>Getting back to the parallel installation topic, Windows has been updated to
>>created versioned DLLs and to generate .fpc files for building against VR
>>Juggler from the command line (yes, that is finally supported again).
>>However, the header and data directories are not currently being versioned
>>the way that they are on non-Windows platforms, and a decision needs to be
>>made regarding whether it is necessary to do that.
>>
>>My vote on this topic is not to version the header or data directories on
>>Windows. Deployment on Windows is fundamentally different than on other
>>operating systems because there is no equivalent of /usr/include (or
>>/usr/local/include) or /usr/share (or /usr/local/share). Rather, software
>>on Windows usually goes into C:\Program Files\<directory> where <directory>
>>can be named with a version. This makes parallel installations easier since
>>the files are separated at a higher level in the directory structure. It
>>also makes it easier to handle Visual C++ project files since they don't
>>have to be updated to track the name of the include directories (which could
>>require a lot of work since there are would be one /I option needed for each
>>Juggler module). Structuring things this way is what the Boost Consulting's
>>slick installer for Boost on Windows does, and I would apply this same
>>argument to CppDOM and GMTL.
>>
>>===========================================================================
>>
>>Thoughts?
>>
>> -Patrick
>>
>>
>>  
>>------------------------------------------------------------------------
>>
>>-------------------------------------------------------------------------
>>Take Surveys. Earn Cash. Influence the Future of IT
>>Join SourceForge.net's Techsay panel and you'll get the chance to share your
>>opinions on IT & business topics through brief surveys -- and earn cash
>>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>>------------------------------------------------------------------------
>>
>>_______________________________________________
>>Xml-cppdom-devel mailing list
>>Xml...@li...
>>https://lists.sourceforge.net/lists/listinfo/xml-cppdom-devel
>>  
>>    
>>
>
>
>-------------------------------------------------------------------------
>Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the chance to share your
>opinions on IT & business topics through brief surveys -- and earn cash
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>_______________________________________________
>Xml-cppdom-devel mailing list
>Xml...@li...
>https://lists.sourceforge.net/lists/listinfo/xml-cppdom-devel
>
>  
>

Re: [xml-cppdom-devel] Versioned directories on Windows

[Aron B. <ar...@ia...>]

I agree with you 100% on this. I think that introducing versioned header 
directories on Windows is only going to further complicate things. I 
can't say that I know how a lot of packages handle this on Windows. But 
I do know that Qt defaults to being installed in C:\Qt\4.1.4\. This 
sounds very similar to how we could handle it. C:\Program 
Files\gmtl\0.5.0  and C:\Program Files\cppdom\0.6.5

-Aron


Patrick Hartling wrote:
> Sorry for the cross posting, but this involves both CppDOM and GMTL. I
> recently made the statements below on the vrjuggler-devel mailing list and
> have received no comments, criticisms, or feedback. This is an important
> issue that needs to be resolved, so here is what I said:
>
> ===========================================================================
>
> Versioned Header and Data Directories on Windows
> ------------------------------------------------
>
> Getting back to the parallel installation topic, Windows has been updated to
> created versioned DLLs and to generate .fpc files for building against VR
> Juggler from the command line (yes, that is finally supported again).
> However, the header and data directories are not currently being versioned
> the way that they are on non-Windows platforms, and a decision needs to be
> made regarding whether it is necessary to do that.
>
> My vote on this topic is not to version the header or data directories on
> Windows. Deployment on Windows is fundamentally different than on other
> operating systems because there is no equivalent of /usr/include (or
> /usr/local/include) or /usr/share (or /usr/local/share). Rather, software
> on Windows usually goes into C:\Program Files\<directory> where <directory>
> can be named with a version. This makes parallel installations easier since
> the files are separated at a higher level in the directory structure. It
> also makes it easier to handle Visual C++ project files since they don't
> have to be updated to track the name of the include directories (which could
> require a lot of work since there are would be one /I option needed for each
> Juggler module). Structuring things this way is what the Boost Consulting's
> slick installer for Boost on Windows does, and I would apply this same
> argument to CppDOM and GMTL.
>
> ===========================================================================
>
> Thoughts?
>
>  -Patrick
>
>
>   
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> ------------------------------------------------------------------------
>
> _______________________________________________
> Xml-cppdom-devel mailing list
> Xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xml-cppdom-devel
>   

[xml-cppdom-devel] Versioned directories on Windows

[Patrick H. <pa...@13...>]

Sorry for the cross posting, but this involves both CppDOM and GMTL. I
recently made the statements below on the vrjuggler-devel mailing list an=
d
have received no comments, criticisms, or feedback. This is an important
issue that needs to be resolved, so here is what I said:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=


Versioned Header and Data Directories on Windows
------------------------------------------------

Getting back to the parallel installation topic, Windows has been updated=
 to
created versioned DLLs and to generate .fpc files for building against VR=

Juggler from the command line (yes, that is finally supported again).
However, the header and data directories are not currently being versione=
d
the way that they are on non-Windows platforms, and a decision needs to b=
e
made regarding whether it is necessary to do that.

My vote on this topic is not to version the header or data directories on=

Windows. Deployment on Windows is fundamentally different than on other
operating systems because there is no equivalent of /usr/include (or
/usr/local/include) or /usr/share (or /usr/local/share). Rather, software=

on Windows usually goes into C:\Program Files\<directory> where <director=
y>
can be named with a version. This makes parallel installations easier sin=
ce
the files are separated at a higher level in the directory structure. It
also makes it easier to handle Visual C++ project files since they don't
have to be updated to track the name of the include directories (which co=
uld
require a lot of work since there are would be one /I option needed for e=
ach
Juggler module). Structuring things this way is what the Boost Consulting=
's
slick installer for Boost on Windows does, and I would apply this same
argument to CppDOM and GMTL.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=


Thoughts?

 -Patrick


--=20
Patrick L. Hartling                    | VP Engineering, Infiscape Corp.
PGP: http://tinyurl.com/2oum9          | http://www.infiscape.com/

[xml-cppdom-devel] CppDOM 0.6.4 released

[Patrick H. <pa...@13...>]

Several builds of the CppDOM 0.6.5 release has just been posted on
SourceForge. The changes in this relate exclusively to Windows:

   1. Added support for automatic linking. Define CPPDOM_AUTO_LINK
      to link against the appropriate debug or release build of the
      static library. Define CPPDOM_DYN_LINK to link against the
      appropriate debug or release build of the dynamic library.
   2. Added support for Visual C++ 8.0 and Windows XP x64 Edition.

 -Patrick


--=20
Patrick L. Hartling                    | VP Engineering, Infiscape Corp.
PGP: http://tinyurl.com/2oum9          | http://www.infiscape.com/

[xml-cppdom-devel] Use Intel Compiler to build cppdom

[Zonghuan Wu <zw...@ca...>]

Hi,

At LITE (Louisiana Immersive Technology Enterprise), we are working on
installing VRJuggler on the SGI Prism workstation running 64-bit Suze
Linux, the CPUs are intel itaniums. Intel C/C++ compilers are required to
be used for getting optimized performance on the 64-bit platform.

When building cppdom, which VRJuggler depends on, lots of error messages
were displayed on the screen if using intel compiler "icc" or "icpc",
while no problem happend when using "g++".

By the way, I had to explicitly change the cppdom SConstruct file to have
Scons use icc (or icpc) as compiler. as cppdom does not recognize my
system and it use tools in standard order for linux.

Anybody knows the trick and can help us out?

Your help is highly appreciated!

Bradley Wu
Research Scientist
LITE (www.lite3d.com)

Re: [xml-cppdom-devel] Splitting up cppdom.h

[Patrick H. <pa...@13...>]

Allen Bierbaum wrote:
> Patrick Hartling wrote:
>=20
>> I am planning to implement automatic linking for CppDOM when building =
with
>> Visual C++, but I have run into what may be a significant problem. I t=
hink
>> that the fact that nearly all the CppDOM declarations are in cppdom.h
>> results in unnecessary exposure of information to code built on top of=

>> CppDOM. That has not necessarily been an issue before, but with automa=
tic
>> linking, any code that includes a header that includes cppdom.h ends u=
p
>> being built in such a way that it gets linked against cppdom.lib (or
>> whichever variant is used).
>>
>> Consider the case of two pieces of code, A and B, where A is a library=
 and B
>> is an application. If A is using CppDOM internally, it has to be linke=
d
>> against cppdom.lib. B, on the other hand, is not using CppDOM at all b=
ut is
>> just using the higher level interface provided by A. From what I have =
seen
>> over the last 2+ years, B should not have to be linked against cppdom.=
lib
>> explicitly, though it would of course have to be linked against A.lib.=

>>
>> Implementing automatic linking with CppDOM as it is currently structur=
ed
>> means putting the #pragma directive in cppdom.h along with everything =
else.
>> Since a library using CppDOM has no convenient mechanism for forward
>> declarations, the library's headers that use cppdom.h expose the whole=

>> CppDOM API along with its own API even when this is totally unnecessar=
y.
>> What I want to do is break up cppdom.h into a collection of headers (N=
ode.h,
>> NodePtr.h, Document.h, DocumentPtr.h, etc.) and corresponding implemen=
tation
>> files. At that point, cppdom.h would be a way to get all the CppDOM
>> declarations just as it is now, thus allowing full backwards compatibi=
lity
>> for existing code. However, code using CppDOM could be updated so as n=
ot to
>> expose the whole CppDOM API through the use of conveniently and centra=
lly
>> defined forward declarations.
>> =20
>>
> It sounds like this last sentence is really the goal of this effort. =20
> Namely make a way that a library using cppdom can include a header to=20
> get the symbols but not require applications that included that same=20
> library header to link against cppdom.  Is this a correct assesment?

Yes.

> If so, I would suggest that before we go to all the trouble of splittin=
g=20
> things up you could first just create the forward declaration header =20
> (maybe something like cppdom_decls.h or something) and then test to mak=
e=20
> sure that this will work the way you envision it with other libraries.

That's not a bad idea. However, I have decided to try a different approac=
h
than breaking up cppdom.h. I changed the usage of the #pragma directive s=
o
that it only does automatic linking when user code requests it. That mean=
s
that code that didn't need to be linked against CppDOM before does not en=
d
up with an embedded comment saying that it needs to be linked against it
now. I am running a build now to test this, and so far it is working. I
haven't built or run any applications yet, however.

> As far as breaking cppdom up, the current structure has never really=20
> bothered me because in order to use cppdom you would pretty much have t=
o=20
> include the headers all the classes defined right now in cppdom.h.  In =

> that way it really is the public interface file.  The internal details =

> like the parser are in other files.  So I guess I am not set against=20
> splitting things up but I think users are going to include cppdom.h=20
> anyway just to cut down on the number of files they have to remember to=
=20
> include.

That's why I said I would retain cppdom.h in a form that gets the same
results that it does now. I guess it just seems "cleaner" to me to have o=
ne
class per file, but perhaps I have written too much Java code in my time.=
 :)

 -Patrick


--=20
Patrick L. Hartling                    | VP Engineering, Infiscape Corp.
PGP: http://tinyurl.com/2oum9          | http://www.infiscape.com/

Re: [xml-cppdom-devel] Splitting up cppdom.h

[Allen B. <al...@vr...>]

Patrick Hartling wrote:

>I am planning to implement automatic linking for CppDOM when building with
>Visual C++, but I have run into what may be a significant problem. I think
>that the fact that nearly all the CppDOM declarations are in cppdom.h
>results in unnecessary exposure of information to code built on top of
>CppDOM. That has not necessarily been an issue before, but with automatic
>linking, any code that includes a header that includes cppdom.h ends up
>being built in such a way that it gets linked against cppdom.lib (or
>whichever variant is used).
>
>Consider the case of two pieces of code, A and B, where A is a library and B
>is an application. If A is using CppDOM internally, it has to be linked
>against cppdom.lib. B, on the other hand, is not using CppDOM at all but is
>just using the higher level interface provided by A. From what I have seen
>over the last 2+ years, B should not have to be linked against cppdom.lib
>explicitly, though it would of course have to be linked against A.lib.
>
>Implementing automatic linking with CppDOM as it is currently structured
>means putting the #pragma directive in cppdom.h along with everything else.
>Since a library using CppDOM has no convenient mechanism for forward
>declarations, the library's headers that use cppdom.h expose the whole
>CppDOM API along with its own API even when this is totally unnecessary.
>What I want to do is break up cppdom.h into a collection of headers (Node.h,
>NodePtr.h, Document.h, DocumentPtr.h, etc.) and corresponding implementation
>files. At that point, cppdom.h would be a way to get all the CppDOM
>declarations just as it is now, thus allowing full backwards compatibility
>for existing code. However, code using CppDOM could be updated so as not to
>expose the whole CppDOM API through the use of conveniently and centrally
>defined forward declarations.
>  
>
It sounds like this last sentence is really the goal of this effort.  
Namely make a way that a library using cppdom can include a header to 
get the symbols but not require applications that included that same 
library header to link against cppdom.  Is this a correct assesment?

If so, I would suggest that before we go to all the trouble of splitting 
things up you could first just create the forward declaration header  
(maybe something like cppdom_decls.h or something) and then test to make 
sure that this will work the way you envision it with other libraries.

As far as breaking cppdom up, the current structure has never really 
bothered me because in order to use cppdom you would pretty much have to 
include the headers all the classes defined right now in cppdom.h.  In 
that way it really is the public interface file.  The internal details 
like the parser are in other files.  So I guess I am not set against 
splitting things up but I think users are going to include cppdom.h 
anyway just to cut down on the number of files they have to remember to 
include.

-Allen

>My question, then, is this: are there any objections to this effort?
>Frankly, it has always annoyed me that cppdom.h is a catch-all for just
>about the whole CppDOM API, and this new issue is the proverbial last straw
>for me. Nevertheless, I do not want to spend the time splitting up the
>cppdom.h if other people would prefer that the code remain structured as it
>is. I can implement the automatic linking without splitting up cppdom.h, but
>it will mean that CppDOM will be exposed indirectly/inadvertently (in the
>form of preprocessor symbols and linker options) to code that did not
>previously need to know anything about it. Not implementing automatic
>linking means that Windows users would have to identify the specific version
>of CppDOM's .lib file against which they want to link.
>
> -Patrick
>
>
>  
>
>------------------------------------------------------------------------
>
>
>-------------------------------------------------------------------------
>Using Tomcat but need to do more? Need to support web services, security?
>Get stuff done quickly with pre-integrated technology to make your job easier
>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Xml-cppdom-devel mailing list
>Xml...@li...
>https://lists.sourceforge.net/lists/listinfo/xml-cppdom-devel
>  
>

Re: [xml-cppdom-devel] Splitting up cppdom.h

[Aron B. <ar...@ia...>]

I completely agree with you on this one. I also get annoyed with 
libraries that include their entire API in a single header. As long as 
it does not break existing applications, I say go for it.

-Aron

Patrick Hartling wrote:
> I am planning to implement automatic linking for CppDOM when building with
> Visual C++, but I have run into what may be a significant problem. I think
> that the fact that nearly all the CppDOM declarations are in cppdom.h
> results in unnecessary exposure of information to code built on top of
> CppDOM. That has not necessarily been an issue before, but with automatic
> linking, any code that includes a header that includes cppdom.h ends up
> being built in such a way that it gets linked against cppdom.lib (or
> whichever variant is used).
>
> Consider the case of two pieces of code, A and B, where A is a library and B
> is an application. If A is using CppDOM internally, it has to be linked
> against cppdom.lib. B, on the other hand, is not using CppDOM at all but is
> just using the higher level interface provided by A. From what I have seen
> over the last 2+ years, B should not have to be linked against cppdom.lib
> explicitly, though it would of course have to be linked against A.lib.
>
> Implementing automatic linking with CppDOM as it is currently structured
> means putting the #pragma directive in cppdom.h along with everything else.
> Since a library using CppDOM has no convenient mechanism for forward
> declarations, the library's headers that use cppdom.h expose the whole
> CppDOM API along with its own API even when this is totally unnecessary.
> What I want to do is break up cppdom.h into a collection of headers (Node.h,
> NodePtr.h, Document.h, DocumentPtr.h, etc.) and corresponding implementation
> files. At that point, cppdom.h would be a way to get all the CppDOM
> declarations just as it is now, thus allowing full backwards compatibility
> for existing code. However, code using CppDOM could be updated so as not to
> expose the whole CppDOM API through the use of conveniently and centrally
> defined forward declarations.
>
> My question, then, is this: are there any objections to this effort?
> Frankly, it has always annoyed me that cppdom.h is a catch-all for just
> about the whole CppDOM API, and this new issue is the proverbial last straw
> for me. Nevertheless, I do not want to spend the time splitting up the
> cppdom.h if other people would prefer that the code remain structured as it
> is. I can implement the automatic linking without splitting up cppdom.h, but
> it will mean that CppDOM will be exposed indirectly/inadvertently (in the
> form of preprocessor symbols and linker options) to code that did not
> previously need to know anything about it. Not implementing automatic
> linking means that Windows users would have to identify the specific version
> of CppDOM's .lib file against which they want to link.
>
>  -Patrick
>
>
>   
> ------------------------------------------------------------------------
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Xml-cppdom-devel mailing list
> Xml...@li...
> https://lists.sourceforge.net/lists/listinfo/xml-cppdom-devel
>