Menu
▾
▴
xml-cppdom-devel — Developer list
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(2) |
Dec
|
| 2004 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
(1) |
Apr
(2) |
May
|
Jun
(4) |
Jul
(7) |
Aug
(1) |
Sep
(5) |
Oct
|
Nov
(1) |
Dec
(2) |
| 2007 |
Jan
(6) |
Feb
(14) |
Mar
|
Apr
|
May
|
Jun
(12) |
Jul
(4) |
Aug
(1) |
Sep
(9) |
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(9) |
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
(1) |
Mar
(4) |
Apr
(6) |
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
(9) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(11) |
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
(4) |
|
From: Doug M. <mc...@ia...> - 2011-04-05 00:10:00
|
On Apr 4, 2011, at 6:44 PM, Patrick Hartling wrote: > On Mar 31, 2011, at 9:53 PM, Doug McCorkle wrote: > >> Hello, >> >> I have attached two patches that correct the usage of scons on windows and I added a missing header. > > What is the minimum required version of SCons after applying the build changes? I haven't been keeping up with SCons API changes/deprecations. I changed it to 2.0 in the SConstruct. I took the liberty of doing this since I am not sure why anyone would really want to run something older than the latest stable release of SCons. Doug |
|
From: Patrick H. <pat...@gm...> - 2011-04-04 23:44:34
|
On Mar 31, 2011, at 9:53 PM, Doug McCorkle wrote: > Hello, > > I have attached two patches that correct the usage of scons on windows and I added a missing header. What is the minimum required version of SCons after applying the build changes? I haven't been keeping up with SCons API changes/deprecations. -Patrick -- Patrick L. Hartling Senior Software Engineer, Priority 5 http://www.priority5.com/ |
|
From: Doug M. <mc...@ia...> - 2011-04-01 02:53:30
|
Hello, I have attached two patches that correct the usage of scons on windows and I added a missing header. Doug |
|
From: SourceForge.net <no...@so...> - 2010-09-04 17:15:42
|
Bugs item #3057617, was opened at 2010-09-01 12:16 Message generated for change (Comment added) made by patrickh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=467781&aid=3057617&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Ryan Pavlik () >Assigned to: Patrick Hartling (patrickh) Summary: Build error using MSVC 2008 Initial Comment: I've attached a patch to fix a build error on MSVC 2008. ---------------------------------------------------------------------- >Comment By: Patrick Hartling (patrickh) Date: 2010-09-04 12:15 Message: Your patch was applied to the 1.0 branch as r664 and to the trunk as r665. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=467781&aid=3057617&group_id=52718 |
|
From: SourceForge.net <no...@so...> - 2010-09-04 16:55:50
|
Bugs item #3057616, was opened at 2010-09-01 12:16 Message generated for change (Comment added) made by patrickh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=467781&aid=3057616&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Ryan Pavlik () Assigned to: Nobody/Anonymous (nobody) Summary: Build issue on Windows with Scons 1.3.0 Initial Comment: I've attached a patch to fix a build issue of 1.0.x on Windows with MSVC and Scons 1.3.0. ---------------------------------------------------------------------- >Comment By: Patrick Hartling (patrickh) Date: 2010-09-04 11:55 Message: Your patch was applied to the 1.0 branch as r661 and to the trunk as r663. Thanks! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=467781&aid=3057616&group_id=52718 |
|
From: SourceForge.net <no...@so...> - 2010-09-01 17:16:38
|
Bugs item #3057617, was opened at 2010-09-01 17:16 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=467781&aid=3057617&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 Resolution: None Priority: 5 Private: No Submitted By: Ryan Pavlik () Assigned to: Nobody/Anonymous (nobody) Summary: Build error using MSVC 2008 Initial Comment: I've attached a patch to fix a build error on MSVC 2008. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=467781&aid=3057617&group_id=52718 |
|
From: SourceForge.net <no...@so...> - 2010-09-01 17:16:04
|
Bugs item #3057616, was opened at 2010-09-01 17:16 Message generated for change (Tracker Item Submitted) made by You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=467781&aid=3057616&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 Resolution: None Priority: 5 Private: No Submitted By: Ryan Pavlik () Assigned to: Nobody/Anonymous (nobody) Summary: Build issue on Windows with Scons 1.3.0 Initial Comment: I've attached a patch to fix a build issue of 1.0.x on Windows with MSVC and Scons 1.3.0. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=467781&aid=3057616&group_id=52718 |
|
From: SourceForge.net <no...@so...> - 2010-05-09 20:49:23
|
Patches item #2990942, was opened at 2010-04-22 10:40 Message generated for change (Comment added) made by patrickh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=467783&aid=2990942&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: jan p. springer (jsd01) >Assigned to: Patrick Hartling (patrickh) Summary: tr1::unordered_map vs. ext/hash_map Initial Comment: gcc 4.x complains about ext/hash_map being deprecated. attached patch adds a code path for gcc >= 4 using tr1/unordered_map instead. ---------------------------------------------------------------------- >Comment By: Patrick Hartling (patrickh) Date: 2010-05-09 15:49 Message: Your patch was applied in r657 on the trunk and r659 on the 1.0 branch. Thanks for this nice improvement. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=467783&aid=2990942&group_id=52718 |
|
From: SourceForge.net <no...@so...> - 2010-05-09 20:48:08
|
Bugs item #2990931, was opened at 2010-04-22 10:13 Message generated for change (Comment added) made by patrickh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=467781&aid=2990931&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: jan p. springer (jsd01) >Assigned to: Patrick Hartling (patrickh) Summary: "using namespace" in header leads to symbol problems Initial Comment: SpiritParser.h opens boost::spirit with a using namespace declaration. involuntary use of the header elsewhere may lead to symbols in libcppdom to be used by applications at runtime on newer compilers (e.g., gcc version 4.4.3 on fedora 12). the attached patch corrects this. ---------------------------------------------------------------------- >Comment By: Patrick Hartling (patrickh) Date: 2010-05-09 15:48 Message: Your patch was applied in r656 on the trunk and r658 on the 1.0 branch. Many thanks for fixing this up! ---------------------------------------------------------------------- Comment By: jan p. springer (jsd01) Date: 2010-04-22 10:14 Message: nearly forgot, the patch is against the svn trunk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=467781&aid=2990931&group_id=52718 |
|
From: SourceForge.net <no...@so...> - 2010-04-22 15:40:59
|
Patches item #2990942, was opened at 2010-04-22 10:40 Message generated for change (Tracker Item Submitted) made by jsd01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=467783&aid=2990942&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 Resolution: None Priority: 5 Private: No Submitted By: jan p. springer (jsd01) Assigned to: Nobody/Anonymous (nobody) Summary: tr1::unordered_map vs. ext/hash_map Initial Comment: gcc 4.x complains about ext/hash_map being deprecated. attached patch adds a code path for gcc >= 4 using tr1/unordered_map instead. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=467783&aid=2990942&group_id=52718 |
|
From: SourceForge.net <no...@so...> - 2010-04-22 15:14:30
|
Bugs item #2990931, was opened at 2010-04-22 10:13 Message generated for change (Comment added) made by jsd01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=467781&aid=2990931&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 Resolution: None Priority: 5 Private: No Submitted By: jan p. springer (jsd01) Assigned to: Nobody/Anonymous (nobody) Summary: "using namespace" in header leads to symbol problems Initial Comment: SpiritParser.h opens boost::spirit with a using namespace declaration. involuntary use of the header elsewhere may lead to symbols in libcppdom to be used by applications at runtime on newer compilers (e.g., gcc version 4.4.3 on fedora 12). the attached patch corrects this. ---------------------------------------------------------------------- >Comment By: jan p. springer (jsd01) Date: 2010-04-22 10:14 Message: nearly forgot, the patch is against the svn trunk. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=467781&aid=2990931&group_id=52718 |
|
From: SourceForge.net <no...@so...> - 2010-04-22 15:13:39
|
Bugs item #2990931, was opened at 2010-04-22 10:13 Message generated for change (Tracker Item Submitted) made by jsd01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=467781&aid=2990931&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 Resolution: None Priority: 5 Private: No Submitted By: jan p. springer (jsd01) Assigned to: Nobody/Anonymous (nobody) Summary: "using namespace" in header leads to symbol problems Initial Comment: SpiritParser.h opens boost::spirit with a using namespace declaration. involuntary use of the header elsewhere may lead to symbols in libcppdom to be used by applications at runtime on newer compilers (e.g., gcc version 4.4.3 on fedora 12). the attached patch corrects this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=467781&aid=2990931&group_id=52718 |
|
From: Carsten N. <car...@gm...> - 2010-04-15 21:58:40
|
Hello Patrick, Patrick Hartling wrote: > I committed your change, Thanks! > but this brings up a point in CppDOM that confuses > me. I think that the CppDOM "cdata" concept is really the DOM text node. I > am not sure if XML CDATA is even supported by CppDOM, but I suppose that I > could write a test to determine that. hm, I had looked at <http://www.w3schools.com/xml/xml_cdata.asp> and from there it seems there is a distinction between parsed character data (PCDATA) which is what you get when using: <some_tag>this is parsed character data</some_tag> and unparsed character data (CDATA) which looks like: <some_tag><![CDATA[unparsed character data here]]></some_tag> The difference seems to be that PCDATA is seen by the xml parser and it looks for more tags in it, so that neesting tags works, while CDATA seems to turn the parser mostly off until the "]]>" sequence is seen. > Perhaps there does not need to be a distinction as far as user-level code is > concerned. What makes me wonder is that actual DOM implementations do > distinguish between the two in their APIs. JDOM, however, has > Element.getText(), which returns what they describe as "the concatenation of > all Text and CDATA nodes returned by getContent()." Note that JDOM has the > class type org.jdom.CDATA which is a subclass of org.jdom.Text. CppDOM > identifies nodes as being of the "cdata" type, but I think that, in CppDOM > terms, this means that the node contains a sequence of characters. hm, I wonder if the distinction is only made so that reading in a file and writing it out again becomes an identity operation - i.e. so that the writer can put in the "<![CDATA[", "]]>" sequences? > I guess as long as CppDOM can properly parse both a CDATA node and a text > node in the input XML, my concerns don't matter. It may really just boil > down to a terminology issue. I think that is the case here. Cheers, Carsten |
|
From: Patrick H. <pat...@gm...> - 2010-04-14 13:37:59
|
Carsten Neumann wrote: > Hello, > > attached patch modifies the tokenizer to preserve newlines in cdata. The > way I understand the xml spec that is what is intended there. The test > still pass, but cdata may now contain some trailing whitespace - not > sure if that is a problem though [1]. > FWIW my use case was that we had some shader code stored in an xml file > that I wanted to read with cppdom, but since the newlines got removed > from things like: > > <fragment_program> > #ifdef HAS_NORMAL_MAP > // read normal from normal map texture > #endif > </fragment_program> > > the preprocessor conditionals stopped working correctly. An alternative > would be to support the "<![CDATA[" "]]>" construct, but that seemed to > require a better understanding of the interaction between tokenizer and > parser. > > Cheers, > Carsten > > [1] The whitespace comes from the indention of </some_tag>: > > <root> > <some_tag> > cdata here > </some_tag> > </root> > > i.e. the cdata string is: "cdata_here\n ". I committed your change, but this brings up a point in CppDOM that confuses me. I think that the CppDOM "cdata" concept is really the DOM text node. I am not sure if XML CDATA is even supported by CppDOM, but I suppose that I could write a test to determine that. The difference is between the following: <fragment_program> #ifdef HAS_NORMAL_MAP // read normal from normal map texture #endif </fragment_program> versus: <fragment_program> <![CDATA[#ifdef HAS_NORMAL_MAP // read normal from normal map texture #endif ]]> </fragment_program> Perhaps there does not need to be a distinction as far as user-level code is concerned. What makes me wonder is that actual DOM implementations do distinguish between the two in their APIs. JDOM, however, has Element.getText(), which returns what they describe as "the concatenation of all Text and CDATA nodes returned by getContent()." Note that JDOM has the class type org.jdom.CDATA which is a subclass of org.jdom.Text. CppDOM identifies nodes as being of the "cdata" type, but I think that, in CppDOM terms, this means that the node contains a sequence of characters. I guess as long as CppDOM can properly parse both a CDATA node and a text node in the input XML, my concerns don't matter. It may really just boil down to a terminology issue. -Patrick -- Patrick L. Hartling Senior Software Engineer, Priority 5 http://www.priority5.com/ |
|
From: Carsten N. <car...@gm...> - 2010-04-13 20:27:13
|
Hello,
attached patch modifies the tokenizer to preserve newlines in cdata. The
way I understand the xml spec that is what is intended there. The test
still pass, but cdata may now contain some trailing whitespace - not
sure if that is a problem though [1].
FWIW my use case was that we had some shader code stored in an xml file
that I wanted to read with cppdom, but since the newlines got removed
from things like:
<fragment_program>
#ifdef HAS_NORMAL_MAP
// read normal from normal map texture
#endif
</fragment_program>
the preprocessor conditionals stopped working correctly. An alternative
would be to support the "<![CDATA[" "]]>" construct, but that seemed to
require a better understanding of the interaction between tokenizer and
parser.
Cheers,
Carsten
[1] The whitespace comes from the indention of </some_tag>:
<root>
<some_tag>
cdata here
</some_tag>
</root>
i.e. the cdata string is: "cdata_here\n ".
|
|
From: Patrick H. <pat...@gm...> - 2010-03-06 17:36:36
|
Version 1.0.1 of CppDOM has been released. This fixes a potential infinite recursion error at run time caused by implicit construction of cppdom::Attribute from any type that does not have an overload of operator<<. Basically, if you have seen mysterious crashes only when cppdom/Attribute.h is included, then this release fixes that. You just need to build and install CppDOM 1.0.1, rebuild your code that uses CppDOM, and you will be all set. The source for this release can be downloaded here: https://sourceforge.net/projects/xml-cppdom/files/ Thanks to Carsten Neumann for tracking this down and submitting the patch! -Patrick -- Patrick L. Hartling Senior Software Engineer, Priority 5 http://www.priority5.com/ |
|
From: Patrick H. <pat...@gm...> - 2010-03-03 16:14:57
|
Carsten Neumann wrote: > Patrick Hartling wrote: >> Carsten Neumann wrote: >>> Attribute has (among others) the following c'tor: > [SNIP] >>> Comments? I can create a patch along these lines if desired. >> >> This sounds good to me. I think that we ran into this problem once >> quite a >> while ago but never identified the source of the problems. Thanks for >> looking into it. > > patch attached. The second one fixes a compile error in > tests/suite/runner.cpp on gcc 4.4.1 (Fedora 11) I ran into. Nice. Thanks! I'll apply those to the trunk. If VR Juggler 2.2 then builds against the trunk without modification, I'll merge your patches to the 1.0 branch and release CppDOM 1.0.1. -Patrick -- Patrick L. Hartling Senior Software Engineer, Priority 5 http://www.priority5.com/ |
|
From: Carsten N. <car...@gm...> - 2010-03-03 15:46:33
|
Patrick Hartling wrote: > Carsten Neumann wrote: >> Attribute has (among others) the following c'tor: [SNIP] >> Comments? I can create a patch along these lines if desired. > > This sounds good to me. I think that we ran into this problem once quite a > while ago but never identified the source of the problems. Thanks for > looking into it. patch attached. The second one fixes a compile error in tests/suite/runner.cpp on gcc 4.4.1 (Fedora 11) I ran into. Cheers, Carsten |
|
From: Patrick H. <pat...@gm...> - 2010-03-03 14:02:49
|
Carsten Neumann wrote:
> Hello,
>
> Attribute has (among others) the following c'tor:
>
> template <class T>
> Attribute(const T& val);
>
> and an output operator:
>
> std::ostream& operator<<(std::ostream& os, const Attribute& att);
>
> together these two constructs will grab any type that does not have a
> operator<< overload of its own and turn it into an infinite recursion at
> runtime (because the above c'tor uses setValue<T>(val) which uses a
> std::ostringstream to convert val into a string representation.
> One possible solution is to make the c'tor template explicit - this has
> the downside that the following needs to be adjusted though:
>
> element->setAttribute("att1", 1);
> element->setAttribute("att2", "something");
>
> to:
>
> element->setAttribute("att1", Attribute(1));
> element->setAttribute("att2", Attribute("something"));
>
> One way to retain the convenience would be to introduce:
>
> template <class T>
> Element::setAttribute(const std::string& attName, const T& attVal)
> {
> setAttribute(attName, Attribute(attVal));
> }
>
> Comments? I can create a patch along these lines if desired.
This sounds good to me. I think that we ran into this problem once quite a
while ago but never identified the source of the problems. Thanks for
looking into it.
-Patrick
--
Patrick L. Hartling
Senior Software Engineer, Priority 5
http://www.priority5.com/
|
|
From: Carsten N. <car...@gm...> - 2010-02-27 23:00:01
|
Hello,
Attribute has (among others) the following c'tor:
template <class T>
Attribute(const T& val);
and an output operator:
std::ostream& operator<<(std::ostream& os, const Attribute& att);
together these two constructs will grab any type that does not have a
operator<< overload of its own and turn it into an infinite recursion at
runtime (because the above c'tor uses setValue<T>(val) which uses a
std::ostringstream to convert val into a string representation.
One possible solution is to make the c'tor template explicit - this has
the downside that the following needs to be adjusted though:
element->setAttribute("att1", 1);
element->setAttribute("att2", "something");
to:
element->setAttribute("att1", Attribute(1));
element->setAttribute("att2", Attribute("something"));
One way to retain the convenience would be to introduce:
template <class T>
Element::setAttribute(const std::string& attName, const T& attVal)
{
setAttribute(attName, Attribute(attVal));
}
Comments? I can create a patch along these lines if desired.
Cheers,
Carsten
|
|
From: Doug M. <mc...@ia...> - 2009-10-29 15:24:53
|
On Oct 29, 2009, at 9:16 AM, Doug McCorkle wrote: > > On Oct 29, 2009, at 8:06 AM, Patrick Hartling wrote: > >> On Oct 28, 2009, at 8:06 PM, Doug McCorkle wrote: >> >>> Hello, >>> >>> What is the proper way to get a 64 bit build of cppdom on Mac OS >>> 10.6? >> >> I was able to build on Snow Leopard without any problems a few weeks >> ago, but now it's giving me trouble. I just committed changes to >> SConsAddons to fix the problems. Both the SConsAddons SVN trunk and >> 1.0 branch will automatically get the updates through running 'svn >> update'. >> >>> We are getting build errors when we ask for a universal build and it >>> does not appear that there is an option for ia64. Thanks for the >>> help. >> >> Please remember that it's usually helpful to post the error messages. > Yes. But I know we did not specify the correct scons options. > >> Also, IA64 is the Itanium architecture. You're thinking of AMD64/ >> EM64T/ >> x86_64/x64. For whatever reason (probably because it's less to type), >> SConsAddons refers to it as x64. > > This did not come up as an option with scons -h. Now we see the x64 option. Thanks! Doug |
|
From: Doug M. <mc...@ia...> - 2009-10-29 14:17:05
|
On Oct 29, 2009, at 8:06 AM, Patrick Hartling wrote: > On Oct 28, 2009, at 8:06 PM, Doug McCorkle wrote: > >> Hello, >> >> What is the proper way to get a 64 bit build of cppdom on Mac OS >> 10.6? > > I was able to build on Snow Leopard without any problems a few weeks > ago, but now it's giving me trouble. I just committed changes to > SConsAddons to fix the problems. Both the SConsAddons SVN trunk and > 1.0 branch will automatically get the updates through running 'svn > update'. > >> We are getting build errors when we ask for a universal build and it >> does not appear that there is an option for ia64. Thanks for the >> help. > > Please remember that it's usually helpful to post the error messages. Yes. But I know we did not specify the correct scons options. > Also, IA64 is the Itanium architecture. You're thinking of AMD64/ > EM64T/ > x86_64/x64. For whatever reason (probably because it's less to type), > SConsAddons refers to it as x64. This did not come up as an option with scons -h. Doug |
|
From: Patrick H. <pat...@gm...> - 2009-10-29 13:06:29
|
On Oct 28, 2009, at 8:06 PM, Doug McCorkle wrote: > Hello, > > What is the proper way to get a 64 bit build of cppdom on Mac OS 10.6? I was able to build on Snow Leopard without any problems a few weeks ago, but now it's giving me trouble. I just committed changes to SConsAddons to fix the problems. Both the SConsAddons SVN trunk and 1.0 branch will automatically get the updates through running 'svn update'. > We are getting build errors when we ask for a universal build and it > does not appear that there is an option for ia64. Thanks for the help. Please remember that it's usually helpful to post the error messages. Also, IA64 is the Itanium architecture. You're thinking of AMD64/EM64T/ x86_64/x64. For whatever reason (probably because it's less to type), SConsAddons refers to it as x64. -Patrick -- Patrick L. Hartling Senior Software Engineer, Priority 5 http://www.priority5.com/ |
|
From: Doug M. <mc...@ia...> - 2009-10-29 01:07:13
|
Hello, What is the proper way to get a 64 bit build of cppdom on Mac OS 10.6? We are getting build errors when we ask for a universal build and it does not appear that there is an option for ia64. Thanks for the help. Doug |
|
From: Doug M. <mc...@ia...> - 2009-07-13 04:32:18
|
On Jul 7, 2009, at 9:51 AM, Doug McCorkle wrote: > > On Jul 7, 2009, at 8:24 AM, Patrick Hartling wrote: > >> Doug McCorkle wrote: >>> >>> [snip] >>> >>>>> >>>>> For now I have hacked GetPlatform and GetArch to return the >>>>> appropriate values for win64 builds but I am running into another >>>>> problem. It appears that the EnvironmentBuilder is specifically >>>>> configured for MSVS 8 which causes problems when trying to build >>>>> with >>>>> MSVS 9. Any thoughts on potential fixes? Can we use the default >>>>> behaviour of SCons 1.2.0 for MSVS builds and not support older >>>>> versions of SCons? Thanks. >>>> >>>> >>>> Oh, right, I forgot about that mess. Give the new SCons support a >>>> try. >>>> If it works, the hacks for Win64 and Visual C++ 8.0 should be >>>> removed. >>>> I don't see any reason to support older versions of SCons, but then >>>> again, I don't have the final say on that. >>>> >>> >>> Do you happen to know how build_env is initialized in the >>> SConstruct? I >>> see it exported and used but it never appears to be configured. >> >> Is it part of the Variants stuff? If not, then I don't know. > > I have something semi working with the latest point release of scons. > Unfortunately, it seems like the variant stuff and the multiple > environments floating around in sca is getting in the way of the new > access to msvs in scons. I should have a more detailed report in a day > or so. The issue is that the variables: MSVS_ARCH and MSVS_VERSION must be set before the Environment is created. When using variants this is done within the variant loop I believe. If the Environment is configured outside without using variants then things are a little more straight forward to correct. In general, the code that is in the msvs_misc function for the 64bit platform can be commented out. Also, there are problems with detecting whether the code is being run on a 64 bit platform. I have been unable to find a method that works other than to read registry values or environment variables. I found notes to this affect in the scons msvs common.py file as well. I think updating SCA to support msvc 8.0 and 9.0 for both 32 and 64 bit platforms would be fairly straight forward. Is it OK to require SCons 1.2.0 for SCA use? Doug |
2 messages has been excluded from this view by a project administrator.
