xml-cppdom-devel — Developer list

[xml-cppdom-devel] CppDOM 0.7.10 released

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

CppDOM 0.7.10 has been posted to SourceForge. This release includes three=

important improvements:

   * A bug in the parsing of empty XML comments has been fixed
   * The Flagpoll .fpc file is ready for use on Windows
   * The Windows installation structure allows switching between the
     optimized and debug-enabled DLL (both linked against the Visual C++
     release runtime) by changing PATH

The source can be downloaded from the following link:

http://sourceforge.net/project/showfiles.php?group_id=3D52718&package_id=3D=
46909&release_id=3D529822

Binary packages for Windows will be available in the next few days. RPMs =
for
several Linux distributions are available from the Infiscape Yum reposito=
ry.
To get started with our repository, install one of the following RPMs:

http://www.infiscape.com/packages/rhel/4/noarch/infiscape-release-1.0-1.e=
l.noarch.rpm
http://www.infiscape.com/packages/rhel/5/noarch/infiscape-release-1.0-1.e=
l.noarch.rpm
http://www.infiscape.com/packages/fedora/6/noarch/infiscape-release-1.0-1=
=2Efc.noarch.rpm
http://www.infiscape.com/packages/fedora/7/noarch/infiscape-release-1.0-1=
=2Efc.noarch.rpm
http://www.infiscape.com/packages/suse/10.2/noarch/infiscape-release-1.0-=
1.suse.noarch.rpm

Other packages will be forthcoming.

 -Patrick


--=20
Patrick L. Hartling
VP Engineering, Infiscape Corp.
http://www.infiscape.com/

[xml-cppdom-devel] CppDOM 0.7.9 released

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

CppDOM 0.7.9 has been posted to SourceForge. This release fixes several b=
ugs
discovered in the 0.7.8 build, most of which were on Mac OS X. No changes=

have been made to the C++ source code.

The source can be downloaded from the following link:

http://sourceforge.net/project/showfiles.php?group_id=3D52718&package_id=3D=
46909&release_id=3D521449

For the moment, there are no Windows binaries for this release since they=

would be no different than the 0.7.8 builds (except for cppdom/version.h)=
=2E
Windows builds will be posted if there is a demand for them, however.

RPMs for several Linux distributions are available from the Infiscape Yum=

repository. To get started with our repository, install one of the follow=
ing
RPMs:

http://www.infiscape.com/packages/rhel/4/noarch/infiscape-release-1.0-1.e=
l.noarch.rpm
http://www.infiscape.com/packages/rhel/5/noarch/infiscape-release-1.0-1.e=
l.noarch.rpm
http://www.infiscape.com/packages/fedora/6/noarch/infiscape-release-1.0-1=
=2Efc.noarch.rpm
http://www.infiscape.com/packages/suse/10.2/noarch/infiscape-release-1.0-=
1.suse.noarch.rpm

Other packages will be forthcoming.

 -Patrick


--=20
Patrick L. Hartling
VP Engineering, Infiscape Corp.
http://www.infiscape.com/

Re: [xml-cppdom-devel] SConstruct patch

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

On Jul 5, 2007, at 9:17 AM, Patrick Hartling wrote:

> Doug McCorkle wrote:
>> On Jun 28, 2007, at 9:06 AM, Doug McCorkle wrote:
>>
>>> On Jun 28, 2007, at 8:36 AM, Patrick Hartling wrote:
>>>
>>>> Doug McCorkle wrote:
>>>>> Hello,
>>>>>
>>>>>      Attached is a patch that changes the SConstruct to encode the
>>>>> relative flagpoll variable in the fpc file rather than utilize the
>>>>> absolute path for prefix.
>>>> With this patch, headers end up getting installed into /include/
>>>> cppdom-0.7.8
>>>> instead of <prefix>/include/cppdom-0.7.8. I think that
>>>> base_inst_paths['include'] plays a more important role than just
>>>> influencing
>>>> what ends up in the generated .fpc file.
>>> Thanks for catching the mistake. Attached is a revised patch. I
>>> also cleaned up some other aspects of the previous patch.
>>>
>>
>> I was just wondering if this patch is ok or if there are also
>> problems with this implementation?
>
> It was fine. I committed it a week ago.
>

OK. The sourceforge veiwsvn must be slow in getting those changes on  
the public page. Thanks!

Doug

Re: [xml-cppdom-devel] SConstruct patch

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

Doug McCorkle wrote:
> On Jun 28, 2007, at 9:06 AM, Doug McCorkle wrote:
>=20
>> On Jun 28, 2007, at 8:36 AM, Patrick Hartling wrote:
>>
>>> Doug McCorkle wrote:
>>>> Hello,
>>>>
>>>>      Attached is a patch that changes the SConstruct to encode the
>>>> relative flagpoll variable in the fpc file rather than utilize the
>>>> absolute path for prefix.
>>> With this patch, headers end up getting installed into /include/=20
>>> cppdom-0.7.8
>>> instead of <prefix>/include/cppdom-0.7.8. I think that
>>> base_inst_paths['include'] plays a more important role than just =20
>>> influencing
>>> what ends up in the generated .fpc file.
>> Thanks for catching the mistake. Attached is a revised patch. I =20
>> also cleaned up some other aspects of the previous patch.
>>
>=20
> I was just wondering if this patch is ok or if there are also =20
> problems with this implementation?

It was fine. I committed it a week ago.

 -Patrick


--=20
Patrick L. Hartling
VP Engineering, Infiscape Corp.
http://www.infiscape.com/

Re: [xml-cppdom-devel] SConstruct patch

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

On Jun 28, 2007, at 9:06 AM, Doug McCorkle wrote:

>
> On Jun 28, 2007, at 8:36 AM, Patrick Hartling wrote:
>
>> Doug McCorkle wrote:
>>> Hello,
>>>
>>>      Attached is a patch that changes the SConstruct to encode the
>>> relative flagpoll variable in the fpc file rather than utilize the
>>> absolute path for prefix.
>>
>> With this patch, headers end up getting installed into /include/ 
>> cppdom-0.7.8
>> instead of <prefix>/include/cppdom-0.7.8. I think that
>> base_inst_paths['include'] plays a more important role than just  
>> influencing
>> what ends up in the generated .fpc file.
>
> Thanks for catching the mistake. Attached is a revised patch. I  
> also cleaned up some other aspects of the previous patch.
>

I was just wondering if this patch is ok or if there are also  
problems with this implementation?

Doug

Re: [xml-cppdom-devel] Build problems with CppDOM 0.7.8 on darwin

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

Patrick Hartling wrote:
> Doug McCorkle wrote:
>> Hello,
>>       I am trying to build CppDOM 0.7.8 on darwin and I get this error=
:
>>
>> using prefix:  /Users/mccdo/Desktop/cppdom-0.7.8/build.darwin/instlink=
s
>> types:  [['debug', 'optimized'], True]
>> libtypes:  [['shared', 'static'], False]
>> archs:  [['ia32', 'ppc', 'ppc64', 'universal'], True]
>>     Processing combo:  type:debug, libtype:['shared', 'static'], =20
>> arch:ia32
>>     Processing combo:  type:debug, libtype:['shared', 'static'], =20
>> arch:ppc
>>
>> scons: warning: Two different environments were specified for target /=
=20
>> Users/mccdo/Desktop/cppdom-0.7.8/build.darwin/instlinks/lib/debug/=20
>> libcppdom-0_7_8.dylib,
>>          but they appear to have the same action: installFunc(target, =
=20
>> source, env)
>> File "/Users/mccdo/Desktop/cppdom-0.7.8/cppdom/SConscript", line 50,  =

>> in ?
>>
>> scons: *** Multiple ways to build the same target were specified =20
>> for: /Users/mccdo/Desktop/cppdom-0.7.8/build.darwin/instlinks/lib/=20
>> debug/libcppdom-0_7_8.dylib  (from ['/Users/mccdo/Desktop/=20
>> cppdom-0.7.8/build.darwin/type-debug--arch-ia32/cppdom/=20
>> libcppdom-0_7_8.dylib'] and from ['libcppdom-0_7_8.dylib'])
>> File "/Users/mccdo/Desktop/cppdom-0.7.8/cppdom/SConscript", line 50,  =

>> in ?
>> mccdo:~/Desktop/cppdom-0.7.8 mccdo$ scons BoostBaseDir=3D/opt/local =20
>> BoostIncludeDir=3D/opt/local/include/boost-1_34
>>
>> The last line shows my build line. Not sure what I am doing wrong.
>=20
> In general, you shouldn't use the Spirit-based parser. As I understand =
it,
> it's slower than the basic XML parser in CppDOM. What I am getting at w=
ith
> this is don't tell the CppDOM build where to find Boost.
>=20
> Other than that, the only way that I can get CppDOM to build on Mac OS =
X is
> to build it as a universal binary. The instructions for that are in the=

> README file. The problem lies in SConsAddons, but I haven't been able t=
o
> figure out what is really going wrong.

I did some more digging into this, and I am not so sure that this is a bu=
g
in SConsAddons but rather a shortcoming of the installation directory
structure currently in use. In any event, I added some more instructions =
to
the README file for post-0.7.8 releases.

The 0.7.8 version of how to build on Mac OS X is as follows:

   On Mac OS X, the build may auto-detect that it can build multiple
   architectures (not necessarily universal binaries), but this case is n=
ot
   currently handled well. SCons will complain that there are multiple wa=
ys
   to build the same target and exit with an error. To work around this,
   specify the desired architecture explicitly (pass var_arch=3Dppc,
   var_arch=3Dia32, or var_arch=3Dppc64 on the scons command line) and di=
sable
   universal binary compilation (pass darwin_universal=3Dno). For example=
, to
   target PowerPC alone, use the following command:

      scons var_arch=3Dppc darwin_universal=3Dno

   Otherwise, build a universal binary:

      scons var_arch=3Duniversal darwin_sdk=3D/Developer/SDKs/MacOSX10.4u=
=2Esdk

 -Patrick



--=20
Patrick L. Hartling
VP Engineering, Infiscape Corp.
http://www.infiscape.com/

Re: [xml-cppdom-devel] SConstruct patch

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

On Jun 28, 2007, at 8:36 AM, Patrick Hartling wrote:

> Doug McCorkle wrote:
>> Hello,
>>
>>      Attached is a patch that changes the SConstruct to encode the
>> relative flagpoll variable in the fpc file rather than utilize the
>> absolute path for prefix.
>
> With this patch, headers end up getting installed into /include/ 
> cppdom-0.7.8
> instead of <prefix>/include/cppdom-0.7.8. I think that
> base_inst_paths['include'] plays a more important role than just  
> influencing
> what ends up in the generated .fpc file.

Thanks for catching the mistake. Attached is a revised patch. I also  
cleaned up some other aspects of the previous patch.

Doug

Re: [xml-cppdom-devel] SConstruct patch

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

Doug McCorkle wrote:
> Hello,
>=20
>      Attached is a patch that changes the SConstruct to encode the
> relative flagpoll variable in the fpc file rather than utilize the
> absolute path for prefix.

With this patch, headers end up getting installed into /include/cppdom-0.=
7.8
instead of <prefix>/include/cppdom-0.7.8. I think that
base_inst_paths['include'] plays a more important role than just influenc=
ing
what ends up in the generated .fpc file.

 -Patrick


--=20
Patrick L. Hartling
VP Engineering, Infiscape Corp.
http://www.infiscape.com/

[xml-cppdom-devel] SConstruct patch

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

Hello,

      Attached is a patch that changes the SConstruct to encode the  
relative flagpoll variable in the fpc file rather than utilize the  
absolute path for prefix.

Doug

Re: [xml-cppdom-devel] Build problems with CppDOM 0.7.8 on darwin

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

>>
>>

[snip]

>> Other than that, the only way that I can get CppDOM to build on Mac
>> OS X is
>> to build it as a universal binary. The instructions for that are in
>> the
>> README file. The problem lies in SConsAddons, but I haven't been
>> able to
>> figure out what is really going wrong.
>
> OK. Now I get this error:

[snip]

>
>
> In regards to SConsAddons on mac, I can build non universal apps with
> it on my mac. Is there some other issue here?
>
> Doug

If I turn testing off then things are good to go.

Doug

Re: [xml-cppdom-devel] Build problems with CppDOM 0.7.8 on darwin

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

On Jun 27, 2007, at 9:39 PM, Patrick Hartling wrote:

> Doug McCorkle wrote:
>> Hello,
>>       I am trying to build CppDOM 0.7.8 on darwin and I get this  
>> error:
>>
>> using prefix:  /Users/mccdo/Desktop/cppdom-0.7.8/build.darwin/ 
>> instlinks
>> types:  [['debug', 'optimized'], True]
>> libtypes:  [['shared', 'static'], False]
>> archs:  [['ia32', 'ppc', 'ppc64', 'universal'], True]
>>     Processing combo:  type:debug, libtype:['shared', 'static'],
>> arch:ia32
>>     Processing combo:  type:debug, libtype:['shared', 'static'],
>> arch:ppc
>>
>> scons: warning: Two different environments were specified for  
>> target /
>> Users/mccdo/Desktop/cppdom-0.7.8/build.darwin/instlinks/lib/debug/
>> libcppdom-0_7_8.dylib,
>>          but they appear to have the same action: installFunc(target,
>> source, env)
>> File "/Users/mccdo/Desktop/cppdom-0.7.8/cppdom/SConscript", line 50,
>> in ?
>>
>> scons: *** Multiple ways to build the same target were specified
>> for: /Users/mccdo/Desktop/cppdom-0.7.8/build.darwin/instlinks/lib/
>> debug/libcppdom-0_7_8.dylib  (from ['/Users/mccdo/Desktop/
>> cppdom-0.7.8/build.darwin/type-debug--arch-ia32/cppdom/
>> libcppdom-0_7_8.dylib'] and from ['libcppdom-0_7_8.dylib'])
>> File "/Users/mccdo/Desktop/cppdom-0.7.8/cppdom/SConscript", line 50,
>> in ?
>> mccdo:~/Desktop/cppdom-0.7.8 mccdo$ scons BoostBaseDir=/opt/local
>> BoostIncludeDir=/opt/local/include/boost-1_34
>>
>> The last line shows my build line. Not sure what I am doing wrong.
>
> In general, you shouldn't use the Spirit-based parser. As I  
> understand it,
> it's slower than the basic XML parser in CppDOM. What I am getting  
> at with
> this is don't tell the CppDOM build where to find Boost.
>
> Other than that, the only way that I can get CppDOM to build on Mac  
> OS X is
> to build it as a universal binary. The instructions for that are in  
> the
> README file. The problem lies in SConsAddons, but I haven't been  
> able to
> figure out what is really going wrong.

OK. Now I get this error:

g++ -o build.darwin/type-optimized--arch-universal/test/suite/ 
TestCases/NodeTest.o -c -O2 -Wall -pipe -arch ppc -arch i386 -arch  
ppc64 -I/opt/local/include -DNDEBUG -Itest2/include/cppdom-0.7.8 - 
Itest -Itest/suite test/suite/TestCases/NodeTest.cpp
/opt/local/include/cppunit/extensions/TestFixtureFactory.h:17:  
warning: 'class CppUnit::TestFixtureFactory' has virtual functions  
but non-virtual destructor
/opt/local/include/cppunit/extensions/TestFixtureFactory.h:17:  
warning: 'class CppUnit::TestFixtureFactory' has virtual functions  
but non-virtual destructor
/opt/local/include/cppunit/extensions/TestFixtureFactory.h: In  
instantiation of  
'CppUnit::ConcretTestFixtureFactory<cppdomtest::NodeTest>':
test/suite/TestCases/NodeTest.h:55:   instantiated from here
/opt/local/include/cppunit/extensions/TestFixtureFactory.h:30:  
warning: 'class  
CppUnit::ConcretTestFixtureFactory<cppdomtest::NodeTest>' has virtual  
functions but non-virtual destructor
/opt/local/include/cppunit/extensions/TestFixtureFactory.h:17:  
warning: 'class CppUnit::TestFixtureFactory' has virtual functions  
but non-virtual destructor
/opt/local/include/cppunit/extensions/TestFixtureFactory.h: In  
instantiation of  
'CppUnit::ConcretTestFixtureFactory<cppdomtest::NodeTest>':
test/suite/TestCases/NodeTest.h:55:   instantiated from here
/opt/local/include/cppunit/extensions/TestFixtureFactory.h:30:  
warning: 'class  
CppUnit::ConcretTestFixtureFactory<cppdomtest::NodeTest>' has virtual  
functions but non-virtual destructor
test/testHelpers.h: In function 'void testHelpers::dump_node 
(cppdom::Node&, int)':
test/testHelpers.h:44: error: 'class cppdom::Node' has no member  
named 'attrib'
test/testHelpers.h:52: error: 'struct std::string' has no member  
named 'getString'
test/suite/TestCases/NodeTest.cpp: In member function 'void  
cppdomtest::NodeTest::testChildAccess()':
test/suite/TestCases/NodeTest.cpp:81: error: 'class cppdom::Node' has  
no member named 'attrib'
test/suite/TestCases/NodeTest.cpp:81: error: expected primary- 
expression before 'int'
test/suite/TestCases/NodeTest.cpp:81: error: expected ',' or ';'  
before 'int'
test/suite/TestCases/NodeTest.cpp:94: error: 'class cppdom::Node' has  
no member named 'attrib'
test/suite/TestCases/NodeTest.cpp:94: error: expected primary- 
expression before 'int'
test/suite/TestCases/NodeTest.cpp:94: error: expected `)' before 'int'
test/suite/TestCases/NodeTest.cpp:94: error: expected `)' before ';'  
token
test/suite/TestCases/NodeTest.cpp:95: error: 'class cppdom::Node' has  
no member named 'attrib'
test/suite/TestCases/NodeTest.cpp:95: error: expected primary- 
expression before 'int'
test/suite/TestCases/NodeTest.cpp:95: error: expected `)' before 'int'
test/suite/TestCases/NodeTest.cpp:95: error: expected `)' before ';'  
token
test/testHelpers.h: In function 'void testHelpers::dump_node 
(cppdom::Node&, int)':
test/testHelpers.h:44: error: 'class cppdom::Node' has no member  
named 'attrib'/opt/local/include/cppunit/extensions/ 
TestFixtureFactory.h: In instantiation of  
'CppUnit::ConcretTestFixtureFactory<cppdomtest::NodeTest>':
test/suite/TestCases/NodeTest.h:55:   instantiated from here
/opt/local/include/cppunit/extensions/TestFixtureFactory.h:30:  
warning: 'class  
CppUnit::ConcretTestFixtureFactory<cppdomtest::NodeTest>' has virtual  
functions but non-virtual destructor

test/testHelpers.h:52: error: 'struct std::string' has no member  
named 'getString'
test/suite/TestCases/NodeTest.cpp: In member function 'void  
cppdomtest::NodeTest::testChildAccess()':
test/suite/TestCases/NodeTest.cpp:81: error: 'class cppdom::Node' has  
no member named 'attrib'
test/suite/TestCases/NodeTest.cpp:81: error: expected primary- 
expression before 'int'
test/suite/TestCases/NodeTest.cpp:81: error: expected ',' or ';'  
before 'int'
test/suite/TestCases/NodeTest.cpp:94: error: 'class cppdom::Node' has  
no member named 'attrib'
test/suite/TestCases/NodeTest.cpp:94: error: expected primary- 
expression before 'int'
test/suite/TestCases/NodeTest.cpp:94: error: expected `)' before 'int'
test/suite/TestCases/NodeTest.cpp:94: error: expected `)' before ';'  
token
test/suite/TestCases/NodeTest.cpp:95: error: 'class cppdom::Node' has  
no member named 'attrib'
test/suite/TestCases/NodeTest.cpp:95: error: expected primary- 
expression before 'int'
test/suite/TestCases/NodeTest.cpp:95: error: expected `)' before 'int'
test/suite/TestCases/NodeTest.cpp:95: error: expected `)' before ';'  
token
test/testHelpers.h: In function 'void testHelpers::dump_node 
(cppdom::Node&, int)':
test/testHelpers.h:44: error: 'class cppdom::Node' has no member  
named 'attrib'
test/testHelpers.h:52: error: 'struct std::string' has no member  
named 'getString'
test/suite/TestCases/NodeTest.cpp: In member function 'void  
cppdomtest::NodeTest::testChildAccess()':
test/suite/TestCases/NodeTest.cpp:81: error: 'class cppdom::Node' has  
no member named 'attrib'
test/suite/TestCases/NodeTest.cpp:81: error: expected primary- 
expression before 'int'
test/suite/TestCases/NodeTest.cpp:81: error: expected ',' or ';'  
before 'int'
test/suite/TestCases/NodeTest.cpp:94: error: 'class cppdom::Node' has  
no member named 'attrib'
test/suite/TestCases/NodeTest.cpp:94: error: expected primary- 
expression before 'int'
test/suite/TestCases/NodeTest.cpp:94: error: expected `)' before 'int'
test/suite/TestCases/NodeTest.cpp:94: error: expected `)' before ';'  
token
test/suite/TestCases/NodeTest.cpp:95: error: 'class cppdom::Node' has  
no member named 'attrib'
test/suite/TestCases/NodeTest.cpp:95: error: expected primary- 
expression before 'int'
test/suite/TestCases/NodeTest.cpp:95: error: expected `)' before 'int'
test/suite/TestCases/NodeTest.cpp:95: error: expected `)' before ';'  
token
lipo: can't open input file: /var/tmp//cclkhF0k.out (No such file or  
directory)
scons: *** [build.darwin/type-optimized--arch-universal/test/suite/ 
TestCases/NodeTest.o] Error 1
scons: building terminated because of errors.
mccdo:~/Desktop/cppdom-0.7.8 mccdo$


In regards to SConsAddons on mac, I can build non universal apps with  
it on my mac. Is there some other issue here?

Doug

Re: [xml-cppdom-devel] Build problems with CppDOM 0.7.8 on darwin

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

Doug McCorkle wrote:
> Hello,
>       I am trying to build CppDOM 0.7.8 on darwin and I get this error:=

>=20
> using prefix:  /Users/mccdo/Desktop/cppdom-0.7.8/build.darwin/instlinks=

> types:  [['debug', 'optimized'], True]
> libtypes:  [['shared', 'static'], False]
> archs:  [['ia32', 'ppc', 'ppc64', 'universal'], True]
>     Processing combo:  type:debug, libtype:['shared', 'static'], =20
> arch:ia32
>     Processing combo:  type:debug, libtype:['shared', 'static'], =20
> arch:ppc
>=20
> scons: warning: Two different environments were specified for target / =

> Users/mccdo/Desktop/cppdom-0.7.8/build.darwin/instlinks/lib/debug/=20
> libcppdom-0_7_8.dylib,
>          but they appear to have the same action: installFunc(target,  =

> source, env)
> File "/Users/mccdo/Desktop/cppdom-0.7.8/cppdom/SConscript", line 50, =20
> in ?
>=20
> scons: *** Multiple ways to build the same target were specified =20
> for: /Users/mccdo/Desktop/cppdom-0.7.8/build.darwin/instlinks/lib/=20
> debug/libcppdom-0_7_8.dylib  (from ['/Users/mccdo/Desktop/=20
> cppdom-0.7.8/build.darwin/type-debug--arch-ia32/cppdom/=20
> libcppdom-0_7_8.dylib'] and from ['libcppdom-0_7_8.dylib'])
> File "/Users/mccdo/Desktop/cppdom-0.7.8/cppdom/SConscript", line 50, =20
> in ?
> mccdo:~/Desktop/cppdom-0.7.8 mccdo$ scons BoostBaseDir=3D/opt/local =20
> BoostIncludeDir=3D/opt/local/include/boost-1_34
>=20
> The last line shows my build line. Not sure what I am doing wrong.

In general, you shouldn't use the Spirit-based parser. As I understand it=
,
it's slower than the basic XML parser in CppDOM. What I am getting at wit=
h
this is don't tell the CppDOM build where to find Boost.

Other than that, the only way that I can get CppDOM to build on Mac OS X =
is
to build it as a universal binary. The instructions for that are in the
README file. The problem lies in SConsAddons, but I haven't been able to
figure out what is really going wrong.

 -Patrick


--=20
Patrick L. Hartling
VP Engineering, Infiscape Corp.
http://www.infiscape.com/

[xml-cppdom-devel] Build problems with CppDOM 0.7.8 on darwin

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

Hello,
      I am trying to build CppDOM 0.7.8 on darwin and I get this error:

using prefix:  /Users/mccdo/Desktop/cppdom-0.7.8/build.darwin/instlinks
types:  [['debug', 'optimized'], True]
libtypes:  [['shared', 'static'], False]
archs:  [['ia32', 'ppc', 'ppc64', 'universal'], True]
    Processing combo:  type:debug, libtype:['shared', 'static'],  
arch:ia32
    Processing combo:  type:debug, libtype:['shared', 'static'],  
arch:ppc

scons: warning: Two different environments were specified for target / 
Users/mccdo/Desktop/cppdom-0.7.8/build.darwin/instlinks/lib/debug/ 
libcppdom-0_7_8.dylib,
         but they appear to have the same action: installFunc(target,  
source, env)
File "/Users/mccdo/Desktop/cppdom-0.7.8/cppdom/SConscript", line 50,  
in ?

scons: *** Multiple ways to build the same target were specified  
for: /Users/mccdo/Desktop/cppdom-0.7.8/build.darwin/instlinks/lib/ 
debug/libcppdom-0_7_8.dylib  (from ['/Users/mccdo/Desktop/ 
cppdom-0.7.8/build.darwin/type-debug--arch-ia32/cppdom/ 
libcppdom-0_7_8.dylib'] and from ['libcppdom-0_7_8.dylib'])
File "/Users/mccdo/Desktop/cppdom-0.7.8/cppdom/SConscript", line 50,  
in ?
mccdo:~/Desktop/cppdom-0.7.8 mccdo$ scons BoostBaseDir=/opt/local  
BoostIncludeDir=/opt/local/include/boost-1_34

The last line shows my build line. Not sure what I am doing wrong.

Doug

[xml-cppdom-devel] CppDOM 0.7.8 released

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

CppDOM 0.7.8 has been posted to SourceForge. This release has several
important changes relative ot the 0.6 series. They are as follows:

   * Headers are installed into a versioned directory to allow for
     parallel CppDOM installations.
   * The use of pkg-config has been replaced by Flagpoll (visit
     https://realityforge.vrsource.org/view/FlagPoll/WebHome for more
     information), also to allow for parallel CppDOM installations.
   * All platforms now use SCons for building the libraries.
   * Improved capabilities for cppdom::OptionRepository.

The source and binaries for Windows can be downloaded from the following =
link:

http://sourceforge.net/project/showfiles.php?group_id=3D52718&package_id=3D=
46909&release_id=3D519203

Note that the Windows x64 build includes both the 32- and 64-bit versions=
 of
the libraries.

RPMs for several Linux distributions are available from the Infiscape Yum=

repository. To get started with our repository, install one of the follow=
ing
RPMs:

http://www.infiscape.com/packages/rhel/4/noarch/infiscape-release-1.0-1.e=
l.noarch.rpm
http://www.infiscape.com/packages/rhel/5/noarch/infiscape-release-1.0-1.e=
l.noarch.rpm
http://www.infiscape.com/packages/fedora/6/noarch/infiscape-release-1.0-1=
=2Efc.noarch.rpm

Other packages will be forthcoming.

 -Patrick


--=20
Patrick L. Hartling
VP Engineering, Infiscape Corp.
http://www.infiscape.com/

Re: [xml-cppdom-devel] [ggt-devel] SConsAddons in gmtl and CppDOM

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

On Jun 27, 2007, at 8:42 AM, Patrick Hartling wrote:

> Doug McCorkle wrote:
>> Hello,
>>        In gmtl and CppDOM it appears that they both utilize a variant
>> of SConsAddons. If that is true would it be possible to have both the
>> packages use SConsAddons rather than having their own variant of the
>> utility? Thanks.
>
> The GMTL build does not use SConsAddons. I believe that parts of  
> its build
> were used as the foundation for SConsAddons, however.
>
Ahh. I thought it was the other way around. Is there any desire to  
move it to SConsAddons?
> The CppDOM trunk now gets the current version of SConsAddons as an SVN
> external reference. The CppDOM 0.6 branch, OTOH, has an old version of
> SConsAddons and most likely does not build with the latest version.
>
I did not know this. Thanks for the update.

Doug

Re: [xml-cppdom-devel] [ggt-devel] SConsAddons in gmtl and CppDOM

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

Doug McCorkle wrote:
> Hello,
>        In gmtl and CppDOM it appears that they both utilize a variant  =

> of SConsAddons. If that is true would it be possible to have both the  =

> packages use SConsAddons rather than having their own variant of the =20
> utility? Thanks.

The GMTL build does not use SConsAddons. I believe that parts of its buil=
d
were used as the foundation for SConsAddons, however.

The CppDOM trunk now gets the current version of SConsAddons as an SVN
external reference. The CppDOM 0.6 branch, OTOH, has an old version of
SConsAddons and most likely does not build with the latest version.

 -Patrick


--=20
Patrick L. Hartling
VP Engineering, Infiscape Corp.
http://www.infiscape.com/

[xml-cppdom-devel] SConsAddons in gmtl and CppDOM

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

Hello,
       In gmtl and CppDOM it appears that they both utilize a variant  
of SConsAddons. If that is true would it be possible to have both the  
packages use SConsAddons rather than having their own variant of the  
utility? Thanks.

Doug

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

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

On Feb 21, 2007, at 10:37 AM, Allen Bierbaum wrote:

> Patrick Hartling wrote:
>> Doug McCorkle wrote:
>>
>>> On Feb 18, 2007, at 8:14 AM, Doug McCorkle wrote:
>>>
>>>
>>>> [snip]
>>>>
>>>>
>>>>>>> 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 prefix
>>>>>>> to the final destination prefix.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>>
>>>>>>> Not everyone is a developer. Installing a package is a separate
>>>>>>> thing from
>>>>>>> building it. Having a developer installation is one thing,  
>>>>>>> but that
>>>>>>> shouldn't interfere with users being able to build and install
>>>>>>> the software.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> Exactly, and that is the point.  The idea is to keep from getting
>>>>>> bitten
>>>>>> by the "developer using a separate build process" problems  
>>>>>> that have
>>>>>> plagued us in the past.  The build the developer uses as part of
>>>>>> their
>>>>>> everyday process is exactly the same as what someone uses for
>>>>>> installation.  (ok, I fibbed a bit here, in the case of  
>>>>>> developer on
>>>>>> linux we replace the copy command with a link command, but all  
>>>>>> the
>>>>>> code
>>>>>> being run is the same)
>>>>>>
>>>>> I am not saying that developers should use a build process that is
>>>>> disjoint
>>>>> from what users do. I think that developers should use a superset
>>>>> of the
>>>>> build process that users need. Users need build+install. If
>>>>> installation
>>>>> does the build first by default (seems like a handy thing for  
>>>>> it to
>>>>> do),
>>>>> then they can skip a step. However, if building does installation
>>>>> whether
>>>>> the user wants it or not, then that is a problem. The two seem  
>>>>> to be
>>>>> intermingled in this case, and that is causing Doug's problem.
>>>>>
>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>>
>>>>>>> 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 get
>>>>>>> regenerated (which seems like a bug).
>>>>>>>
>>>>>> That is definitely a bug.  It should be regenerated.  Running the
>>>>>> build
>>>>>> at any point should generate all files again that need to be
>>>>>> changed for
>>>>>> the new installation path.  That is the whole point of the single
>>>>>> build
>>>>>> process. :)
>>>>>>
>>>>>> I don't have time to look at this today, but I will do what I  
>>>>>> can to
>>>>>> help out.
>>>>>>
>>>>> Wasn't there a change made to the CppDOM build to work around a  
>>>>> bug
>>>>> in SCons
>>>>> where it would scan the entire installation prefix? The result
>>>>> would be that
>>>>> installation would hang if the installation prefix was the root  
>>>>> of a
>>>>> directory tree of even moderate size. I can't find the revision
>>>>> where that
>>>>> happened, so maybe I an thinking of a different project. Being an
>>>>> SCons
>>>>> novice at best, it seems to me that the bug is that the
>>>>> installation prefix
>>>>> is not seen by SCons as being a dependency of cppdom.fpc, and this
>>>>> is what
>>>>> causes the problem. If that is the problem, is there a simple fix?
>>>>>
>>>>>
>>>> [snip]
>>>>
>>>> I understand that there may be some differences in thought in how
>>>> builds should work but what is the solution to the problems at  
>>>> hand?
>>>> I am somewhat confused on what would need to be done to address  
>>>> some
>>>> of the issues that were discussed in this thread.
>>>>
>>>>
>>> Anymore thoughts on these issues?
>>>
>>
>> I don't know how to fix the bug that you are seeing. You know  
>> SCons better
>> than I do. If you have a fix, submit it, and I will check it in.  
>> Allen's
>> silence is usually an indication that he has lost interest or has  
>> no time to
>> pursue the matter further.
>>
> Option 2 :)
>
> I agree with Patrick.  Let's see if we can get the bug fixed and go  
> from
> there.
>

I am happy to do that. I was looking at the issue more and it seems  
that much of the SConsAddons tools would help with some of these  
issues. Is that an option to consider or is patching what is there  
the preferred option at this point?

Doug

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

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

Patrick Hartling wrote:
> Doug McCorkle wrote:
>   
>> On Feb 18, 2007, at 8:14 AM, Doug McCorkle wrote:
>>
>>     
>>> [snip]
>>>
>>>       
>>>>>> 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 prefix
>>>>>> to the final destination prefix.
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> 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.
>>>>>>>
>>>>>>>               
>>>>>> Not everyone is a developer. Installing a package is a separate
>>>>>> thing from
>>>>>> building it. Having a developer installation is one thing, but that
>>>>>> shouldn't interfere with users being able to build and install
>>>>>> the software.
>>>>>>
>>>>>>
>>>>>>             
>>>>> Exactly, and that is the point.  The idea is to keep from getting
>>>>> bitten
>>>>> by the "developer using a separate build process" problems that have
>>>>> plagued us in the past.  The build the developer uses as part of
>>>>> their
>>>>> everyday process is exactly the same as what someone uses for
>>>>> installation.  (ok, I fibbed a bit here, in the case of developer on
>>>>> linux we replace the copy command with a link command, but all the
>>>>> code
>>>>> being run is the same)
>>>>>           
>>>> I am not saying that developers should use a build process that is
>>>> disjoint
>>>> from what users do. I think that developers should use a superset
>>>> of the
>>>> build process that users need. Users need build+install. If
>>>> installation
>>>> does the build first by default (seems like a handy thing for it to
>>>> do),
>>>> then they can skip a step. However, if building does installation
>>>> whether
>>>> the user wants it or not, then that is a problem. The two seem to be
>>>> intermingled in this case, and that is causing Doug's problem.
>>>>
>>>>         
>>>>>>> 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.
>>>>>>>
>>>>>>>               
>>>>>> 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 get
>>>>>> regenerated (which seems like a bug).
>>>>>>             
>>>>> That is definitely a bug.  It should be regenerated.  Running the
>>>>> build
>>>>> at any point should generate all files again that need to be
>>>>> changed for
>>>>> the new installation path.  That is the whole point of the single
>>>>> build
>>>>> process. :)
>>>>>
>>>>> I don't have time to look at this today, but I will do what I can to
>>>>> help out.
>>>>>           
>>>> Wasn't there a change made to the CppDOM build to work around a bug
>>>> in SCons
>>>> where it would scan the entire installation prefix? The result
>>>> would be that
>>>> installation would hang if the installation prefix was the root of a
>>>> directory tree of even moderate size. I can't find the revision
>>>> where that
>>>> happened, so maybe I an thinking of a different project. Being an
>>>> SCons
>>>> novice at best, it seems to me that the bug is that the
>>>> installation prefix
>>>> is not seen by SCons as being a dependency of cppdom.fpc, and this
>>>> is what
>>>> causes the problem. If that is the problem, is there a simple fix?
>>>>
>>>>         
>>> [snip]
>>>
>>> I understand that there may be some differences in thought in how
>>> builds should work but what is the solution to the problems at hand?
>>> I am somewhat confused on what would need to be done to address some
>>> of the issues that were discussed in this thread.
>>>
>>>       
>> Anymore thoughts on these issues?
>>     
>
> I don't know how to fix the bug that you are seeing. You know SCons better
> than I do. If you have a fix, submit it, and I will check it in. Allen's
> silence is usually an indication that he has lost interest or has no time to
> pursue the matter further.
>   
Option 2 :)

I agree with Patrick.  Let's see if we can get the bug fixed and go from 
there.

-Allen

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

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

Doug McCorkle wrote:
> On Feb 18, 2007, at 8:14 AM, Doug McCorkle wrote:
>=20
>>>
>> [snip]
>>
>>>>> 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 prefix
>>>>> to the final destination prefix.
>>>>>
>>>>>
>>>>>> 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.
>>>>>>
>>>>> Not everyone is a developer. Installing a package is a separate
>>>>> thing from
>>>>> building it. Having a developer installation is one thing, but that=

>>>>> shouldn't interfere with users being able to build and install
>>>>> the software.
>>>>>
>>>>>
>>>> Exactly, and that is the point.  The idea is to keep from getting
>>>> bitten
>>>> by the "developer using a separate build process" problems that have=

>>>> plagued us in the past.  The build the developer uses as part of
>>>> their
>>>> everyday process is exactly the same as what someone uses for
>>>> installation.  (ok, I fibbed a bit here, in the case of developer on=

>>>> linux we replace the copy command with a link command, but all the
>>>> code
>>>> being run is the same)
>>> I am not saying that developers should use a build process that is
>>> disjoint
>>> from what users do. I think that developers should use a superset
>>> of the
>>> build process that users need. Users need build+install. If
>>> installation
>>> does the build first by default (seems like a handy thing for it to
>>> do),
>>> then they can skip a step. However, if building does installation
>>> whether
>>> the user wants it or not, then that is a problem. The two seem to be
>>> intermingled in this case, and that is causing Doug's problem.
>>>
>>>>>> 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.
>>>>>>
>>>>> 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 get
>>>>> regenerated (which seems like a bug).
>>>> That is definitely a bug.  It should be regenerated.  Running the
>>>> build
>>>> at any point should generate all files again that need to be
>>>> changed for
>>>> the new installation path.  That is the whole point of the single
>>>> build
>>>> process. :)
>>>>
>>>> I don't have time to look at this today, but I will do what I can to=

>>>> help out.
>>> Wasn't there a change made to the CppDOM build to work around a bug
>>> in SCons
>>> where it would scan the entire installation prefix? The result
>>> would be that
>>> installation would hang if the installation prefix was the root of a
>>> directory tree of even moderate size. I can't find the revision
>>> where that
>>> happened, so maybe I an thinking of a different project. Being an
>>> SCons
>>> novice at best, it seems to me that the bug is that the
>>> installation prefix
>>> is not seen by SCons as being a dependency of cppdom.fpc, and this
>>> is what
>>> causes the problem. If that is the problem, is there a simple fix?
>>>
>> [snip]
>>
>> I understand that there may be some differences in thought in how
>> builds should work but what is the solution to the problems at hand?
>> I am somewhat confused on what would need to be done to address some
>> of the issues that were discussed in this thread.
>>
>=20
> Anymore thoughts on these issues?

I don't know how to fix the bug that you are seeing. You know SCons bette=
r
than I do. If you have a fix, submit it, and I will check it in. Allen's
silence is usually an indication that he has lost interest or has no time=
 to
pursue the matter further.

 -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 18, 2007, at 8:14 AM, Doug McCorkle wrote:

>>
>>
> [snip]
>
>>>> 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 prefix
>>>> to the final destination prefix.
>>>>
>>>>
>>>>> 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.
>>>>>
>>>> Not everyone is a developer. Installing a package is a separate
>>>> thing from
>>>> building it. Having a developer installation is one thing, but that
>>>> shouldn't interfere with users being able to build and install
>>>> the software.
>>>>
>>>>
>>> Exactly, and that is the point.  The idea is to keep from getting
>>> bitten
>>> by the "developer using a separate build process" problems that have
>>> plagued us in the past.  The build the developer uses as part of
>>> their
>>> everyday process is exactly the same as what someone uses for
>>> installation.  (ok, I fibbed a bit here, in the case of developer on
>>> linux we replace the copy command with a link command, but all the
>>> code
>>> being run is the same)
>>
>> I am not saying that developers should use a build process that is
>> disjoint
>> from what users do. I think that developers should use a superset
>> of the
>> build process that users need. Users need build+install. If
>> installation
>> does the build first by default (seems like a handy thing for it to
>> do),
>> then they can skip a step. However, if building does installation
>> whether
>> the user wants it or not, then that is a problem. The two seem to be
>> intermingled in this case, and that is causing Doug's problem.
>>
>>>>> 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.
>>>>>
>>>> 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 get
>>>> regenerated (which seems like a bug).
>>> That is definitely a bug.  It should be regenerated.  Running the
>>> build
>>> at any point should generate all files again that need to be
>>> changed for
>>> the new installation path.  That is the whole point of the single
>>> build
>>> process. :)
>>>
>>> I don't have time to look at this today, but I will do what I can to
>>> help out.
>>
>> Wasn't there a change made to the CppDOM build to work around a bug
>> in SCons
>> where it would scan the entire installation prefix? The result
>> would be that
>> installation would hang if the installation prefix was the root of a
>> directory tree of even moderate size. I can't find the revision
>> where that
>> happened, so maybe I an thinking of a different project. Being an
>> SCons
>> novice at best, it seems to me that the bug is that the
>> installation prefix
>> is not seen by SCons as being a dependency of cppdom.fpc, and this
>> is what
>> causes the problem. If that is the problem, is there a simple fix?
>>
>
> [snip]
>
> I understand that there may be some differences in thought in how
> builds should work but what is the solution to the problems at hand?
> I am somewhat confused on what would need to be done to address some
> of the issues that were discussed in this thread.
>

Anymore thoughts on these issues?

Doug

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

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

>
>
[snip]

>>> 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 prefix
>>> to the final destination prefix.
>>>
>>>
>>>> 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.
>>>>
>>> Not everyone is a developer. Installing a package is a separate  
>>> thing from
>>> building it. Having a developer installation is one thing, but that
>>> shouldn't interfere with users being able to build and install  
>>> the software.
>>>
>>>
>> Exactly, and that is the point.  The idea is to keep from getting  
>> bitten
>> by the "developer using a separate build process" problems that have
>> plagued us in the past.  The build the developer uses as part of  
>> their
>> everyday process is exactly the same as what someone uses for
>> installation.  (ok, I fibbed a bit here, in the case of developer on
>> linux we replace the copy command with a link command, but all the  
>> code
>> being run is the same)
>
> I am not saying that developers should use a build process that is  
> disjoint
> from what users do. I think that developers should use a superset  
> of the
> build process that users need. Users need build+install. If  
> installation
> does the build first by default (seems like a handy thing for it to  
> do),
> then they can skip a step. However, if building does installation  
> whether
> the user wants it or not, then that is a problem. The two seem to be
> intermingled in this case, and that is causing Doug's problem.
>
>>>> 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.
>>>>
>>> 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 get
>>> regenerated (which seems like a bug).
>> That is definitely a bug.  It should be regenerated.  Running the  
>> build
>> at any point should generate all files again that need to be  
>> changed for
>> the new installation path.  That is the whole point of the single  
>> build
>> process. :)
>>
>> I don't have time to look at this today, but I will do what I can to
>> help out.
>
> Wasn't there a change made to the CppDOM build to work around a bug  
> in SCons
> where it would scan the entire installation prefix? The result  
> would be that
> installation would hang if the installation prefix was the root of a
> directory tree of even moderate size. I can't find the revision  
> where that
> happened, so maybe I an thinking of a different project. Being an  
> SCons
> novice at best, it seems to me that the bug is that the  
> installation prefix
> is not seen by SCons as being a dependency of cppdom.fpc, and this  
> is what
> causes the problem. If that is the problem, is there a simple fix?
>

[snip]

I understand that there may be some differences in thought in how  
builds should work but what is the solution to the problems at hand?  
I am somewhat confused on what would need to be done to address some  
of the issues that were discussed in this thread.

Doug

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

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

Allen Bierbaum wrote:
> Patrick Hartling wrote:
>> Allen Bierbaum wrote:
>>  =20
>>> Patrick Hartling wrote:
>>>    =20
>>>> Doug McCorkle wrote:
>>>>  =20
>>>>      =20
>>>>> Hello,
>>>>>      Currently, when building cppdom, headers and libs are installe=
d =20
>>>>> in prefix even if the install target is not listed. This causes =20
>>>>> issues when trying to make cppdom accessible through MacPorts. In  =

>>>>> general this seems to be somewhat of a problem.
>>>>>    =20
>>>>>        =20
>>> Doug:
>>>
>>> I am coming to this a little late, but what is the problem building=20
>>> inside MacPorts?  Is there a requirement that build happens separatel=
y=20
>>> from install?
>>>    =20
>> All packaging utilities that I know of separate building from installi=
ng.
>> Watching MacPorts builds run, they definitely do this, though I don't =
know
>> if it is a strict requirement. I bet that it is, though.
>>
>>  =20
>>> cppdom is definitely not designed to do that.  It has been designed t=
o=20
>>> follow a fairly common best practice of having one command that does =
a=20
>>> 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. :).
>>>    =20
>> Where is this stated as being a best practice?=20
> Many software engineering techniques have concepts similar to this one.=
 =20
> They all revolve around continuous integration=20
> (http://en.wikipedia.org/wiki/Continuous_integration).

What is described here sounds to me like something that wraps a
build/install/test process. Why should it preclude the separation of the
build and installation steps? If nothing else, it seems that one could wr=
ite
a target of the build such as 'universe' that performs the individual ste=
ps
automatically.

> The main point=20
> being that a full build is always happening and that the user can get=20
> from code to fully complete build in one step with nothing to manual=20
> processes in between.

Why should that prevent the user from being able to run the steps individ=
ually?

> This is exactly the type of thing that an rpm=20
> spec file is capturing but the rpc spec file would allow wrapping=20
> multi-step builds.

I don't think that most RPMs would do continuous integration. From the
linked description, it sounds like an RPM can be a *product* of continuou=
s
integration rather than the *means*. Actually, as far as single-step
processes go, an RPM by itself is completely outside of that arena becaus=
e
you have to build an RPM and then install it. These are inherently separa=
te
steps using different commands (rpmbuild first, then rpm).

You could wrap the RPM creation and installation process to turn it into =
a
single step, but the low-level process is still multiple steps. IMHO, the=

same thing should be true of building software. The build is made up of
distinct steps, and developers would always be running all of them. (Ther=
e
is the continuous integration.) However, end users don't need all of them=

and should have the option of doing only what they need. They will still =
be
running steps that developers run, but they don't run all of them.

I think that I misunderstood what you were referring to when you brought =
up
the "best practice" term. I thought that you meant that not separating
building and installation is a best practice, but I believe that what you=

meant is that the CppDOM build is designed to allow for continuous
integration usage. As I will try to explain below, the CppDOM build as it=

stands right now does not address the needs of end users. Rather, it is
designed for developers needing continuous integration.

>> I would think that nearly
>> every library in existence allows for separate build and install steps=
=2E
>> Those that don't are going to make packaging a pain. For example, when=
 you
>> build an RPM to be installed in /usr, you don't actually want it to go=
 into
>> /usr during the packaging process. It has to go into a staging area (w=
hich
>> is something that MacPorts uses) wherein the actual package is created=
=2E So,
>> there end up being two installation trees: the staging area using duri=
ng
>> packaging and the final destination when the package is installed.=20
> I guess I am missing something here.  Why is the staging area ever=20
> needed.

Well, for one thing, it would take a very experienced person to write a s=
pec
file that works correctly on the first try. The staging area can be clear=
ed
out in one fell swoop if something goes wrong during the packaging phase
(which happens all the time in my [limited] experience). Beyond that, hav=
ing
the clean staging area for a given package makes it much easier for rpmbu=
ild
to examine just exactly what is being packaged. If it had to scan all of
/usr every time, it would be a completely unusable tool.

> If you know you want to end up calling install with a=20
> destination path, why not just call install from the beginning and skip=
=20
> the first step?

You can certainly do that, but that doesn't have anything to do with the =
use
of a staging area. You just don't put anything in the %build section of t=
he
spec file. However, just about all software has separate build and instal=
l
phases, and in some (most?) cases, it makes a lot of sense to separate th=
e
two when building the RPM.

> I think there must be a requirement here that I am just=20
> missing.

I think you have some misconceptions about packaging processes. For one, =
I
did not make it clear that the staging area is used during the installati=
on
and packaging phases only. There is a separate place where building occur=
s.
Basically, it mimics just what you would do if you were building the
software and installing it to /usr as root. However, you don't have to be=

root to run rpmbuild (and to my understanding, it is not recommended that=

root run rpmbuild), and it installs into a "clean room" of sorts before
packaging.

>> If you
>> look at the RPM spec file for CppDOM, you'll see a hack where cppdom.f=
pc
>> gets edited after running 'scons install' to change the staging area p=
refix
>> to the final destination prefix.
>>
>>  =20
>>> That way developers are *always* using the same build=20
>>> paths that are used by users and packages to install the tool and the=
re=20
>>> are no special hoops to jump through to install or package the=20
>>> software.
>>>    =20
>> Not everyone is a developer. Installing a package is a separate thing =
from
>> building it. Having a developer installation is one thing, but that
>> shouldn't interfere with users being able to build and install the sof=
tware.
>>
>>  =20
> Exactly, and that is the point.  The idea is to keep from getting bitte=
n=20
> by the "developer using a separate build process" problems that have=20
> plagued us in the past.  The build the developer uses as part of their =

> everyday process is exactly the same as what someone uses for=20
> installation.  (ok, I fibbed a bit here, in the case of developer on=20
> linux we replace the copy command with a link command, but all the code=
=20
> being run is the same)

I am not saying that developers should use a build process that is disjoi=
nt
from what users do. I think that developers should use a superset of the
build process that users need. Users need build+install. If installation
does the build first by default (seems like a handy thing for it to do),
then they can skip a step. However, if building does installation whether=

the user wants it or not, then that is a problem. The two seem to be
intermingled in this case, and that is causing Doug's problem.

>>> 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.
>>>
>>> If you really need the build and install separated, you could do=20
>>> 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 o=
n=20
>>> the first call, but it should work for you.
>>>    =20
>> I am just about positive that that process won't work because cppdom.f=
pc
>> gets generated as part of the build. If the prefix changes, it doesn't=
 get
>> regenerated (which seems like a bug).=20
> That is definitely a bug.  It should be regenerated.  Running the build=
=20
> at any point should generate all files again that need to be changed fo=
r=20
> the new installation path.  That is the whole point of the single build=
=20
> process. :)
>=20
> I don't have time to look at this today, but I will do what I can to=20
> help out.

Wasn't there a change made to the CppDOM build to work around a bug in SC=
ons
where it would scan the entire installation prefix? The result would be t=
hat
installation would hang if the installation prefix was the root of a
directory tree of even moderate size. I can't find the revision where tha=
t
happened, so maybe I an thinking of a different project. Being an SCons
novice at best, it seems to me that the bug is that the installation pref=
ix
is not seen by SCons as being a dependency of cppdom.fpc, and this is wha=
t
causes the problem. If that is the problem, is there a simple fix?

 -Patrick

>> This is something that I know I have
>> seen, and this exact usage is what I was alluding to earlier when I sa=
id
>> "running the build separately from the installation doesn't work well.=
"
>>
>>  -Patrick
>>
>>  =20
>>>> That sounds like bad behavior in general. Software shouldn't be inst=
alling
>>>> itself unless told to do so.
>>>>
>>>> The CppDOM build is in pretty bad shape and hasn't ever been quite w=
hat I
>>>> would call ideal. The installation part has never really worked corr=
ectly,
>>>> but I don't think I have seen this specific behavior. What I have se=
en is
>>>> that running the build separately from the installation doesn't work=
 well,
>>>> but the build certainly should support a two-step build+install proc=
ess.
>>>> What version are you using?
>>>>
>>>>  =20
>>>>      =20
>>>>> I "fixed" the problem =20
>>>>> by adding guards in the scons files but that may not be the solutio=
n =20
>>>>> everyone is looking for. Thoughts?
>>>>>    =20
>>>>>        =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:
> Allen Bierbaum wrote:
>   
>> 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?
>>     
>
> All packaging utilities that I know of separate building from installing.
> Watching MacPorts builds run, they definitely do this, though I don't know
> 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 
>> recommended to have this run the testsuite, but we don't have that in 
>> there yet. :).
>>     
>
> Where is this stated as being a best practice? 
Many software engineering techniques have concepts similar to this one.  
They all revolve around continuous integration 
(http://en.wikipedia.org/wiki/Continuous_integration).  The main point 
being that a full build is always happening and that the user can get 
from code to fully complete build in one step with nothing to manual 
processes in between.  This is exactly the type of thing that an rpm 
spec file is capturing but the rpc spec file would allow wrapping 
multi-step builds.

> 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 you
> build an RPM to be installed in /usr, you don't actually want it to go into
> /usr during the packaging process. It has to go into a staging area (which
> is something that MacPorts uses) wherein the actual package is created. So,
> there end up being two installation trees: the staging area using during
> packaging and the final destination when the package is installed. 
I guess I am missing something here.  Why is the staging area ever 
needed.  If you know you want to end up calling install with a 
destination path, why not just call install from the beginning and skip 
the first step?  I think there must be a requirement here that I am just 
missing.
> 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 prefix
> to the final destination prefix.
>
>   
>> 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.
>>     
>
> Not everyone is a developer. Installing a package is a separate thing from
> building it. Having a developer installation is one thing, but that
> shouldn't interfere with users being able to build and install the software.
>
>   
Exactly, and that is the point.  The idea is to keep from getting bitten 
by the "developer using a separate build process" problems that have 
plagued us in the past.  The build the developer uses as part of their 
everyday process is exactly the same as what someone uses for 
installation.  (ok, I fibbed a bit here, in the case of developer on 
linux we replace the copy command with a link command, but all the code 
being run is the same)

>> 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.
>>     
>
> 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 get
> regenerated (which seems like a bug). 
That is definitely a bug.  It should be regenerated.  Running the build 
at any point should generate all files again that need to be changed for 
the new installation path.  That is the whole point of the single build 
process. :)

I don't have time to look at this today, but I will do what I can to 
help out.

-Allen

> This is something that I know I have
> 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 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

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

> Allen Bierbaum wrote:
>> 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?
>
> All packaging utilities that I know of separate building from installin=
g.
> Watching MacPorts builds run, they definitely do this, though I don't k=
now
> if it is a strict requirement. I bet that it is, though.
>

This is a strict requirement of MacPorts because it defaults to autoconf
tools and stages the build before intsalling therefore when files appear
in the true installation dir /opt/local that it did not put there MacPort=
s
complains.
>> 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. :).
>
> Where is this stated as being a best practice? I would think that nearl=
y
> 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 =
you
> build an RPM to be installed in /usr, you don't actually want it to go
> into
> /usr during the packaging process. It has to go into a staging area (wh=
ich
> is something that MacPorts uses) wherein the actual package is created.
> So,
> there end up being two installation trees: the staging area using durin=
g
> packaging and the final destination when the package is installed. If y=
ou
> look at the RPM spec file for CppDOM, you'll see a hack where cppdom.fp=
c
> gets edited after running 'scons install' to change the staging area
> prefix
> to the final destination prefix.
>
>> That way developers are *always* using the same build
>> paths that are used by users and packages to install the tool and ther=
e
>> are no special hoops to jump through to install or package the
>> software.
>
> Not everyone is a developer. Installing a package is a separate thing f=
rom
> building it. Having a developer installation is one thing, but that
> shouldn't interfere with users being able to build and install 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
>>
I understand the points above but I can not make it work correctly with o=
r
without prefix being specified.

>> 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.fp=
c
> gets generated as part of the build. If the prefix changes, it doesn't =
get
> regenerated (which seems like a bug). This is something that I know I h=
ave
> seen, and this exact usage is what I was alluding to earlier when I sai=
d
> "running the build separately from the installation doesn't work well."
>
I see the same thing you do Patrick. These files do not seem to be
regnerated properly.

[snip]

Doug