From karra.mallibabu at gmail.com Wed Jan 2 07:25:46 2013 From: karra.mallibabu at gmail.com (Mallibabu karra) Date: Wed Jan 2 07:13:06 2013 Subject: [xsd-users] Re: The results of your email commands In-Reply-To: References: Message-ID: I am new to codesynthesis. I am getting a error when i try to run the example project hello xsd-3.3.0-i686-windows\examples\cxx\tree\hello\hello.hxx(42): fatal error C1083: Cannot open include file: 'xsd/cxx/config.hxx': No such file or directory Regards, Mallibabu On Wed, Jan 2, 2013 at 5:34 PM, wrote: > I am new to codesynthesis. > I am getting a error when i try to run the example project hello > > xsd-3.3.0-i686-windows\examples\cxx\tree\hello\hello.hxx(42): fatal error > C1083: Cannot open include file: 'xsd/cxx/config.hxx': No such file or > directory > > Regards, > Mallibabu > From salva.brice at gmail.com Wed Jan 2 07:42:39 2013 From: salva.brice at gmail.com (brice salva) Date: Wed Jan 2 07:30:18 2013 Subject: [xsd-users] Inconsistency in Qname serialization/parsing In-Reply-To: References: Message-ID: Hi Boris, In line with your comment, I have just added the suffix explicitly at the DOM creation step and now the namespace of the root element is prefixed and my generated xml does not contain a default namespace anymore, which is perfect. Using the xml_schema::Qname constructor with the namespace as first parameter and the value as second parameter allows me to specify the appropriate prefix in the soap fault Value element. Thanks for the time spent on my questions. Best Regards, Brice On Mon, Dec 31, 2012 at 6:52 PM, Boris Kolpackov wrote: > Hi Brice, > > brice salva writes: > > > Yet, with xsd codesynthesis, I cannot customize the default namespace > > prefix when I use the *element-type* and *element-map* parse/serialize > > methods to exchange xml messages (no properties as parameter). > > With element type/map you create the DOM document into which you > will be serializing yourself which means that you will need to > establish the namespace-prefix yourself as well. In your case, > this should be as simple as adding the "env:" prefix to the name > you pass as the second argument to createDocument() (see the > 'messaging' example for a reference). > > You can also add other mappings by simply adding DOM attributes. > Q 3.1, "How do I create an empty Xerces-C++ DOM document?" in the > C++/Tree FAQ shows how to do this: > > http://wiki.codesynthesis.com/Tree/FAQ > > Boris > From boris at codesynthesis.com Wed Jan 2 12:06:33 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Jan 2 11:17:39 2013 Subject: [xsd-users] Re: The results of your email commands In-Reply-To: References: Message-ID: Hi Mallibabu, Mallibabu karra writes: > xsd-3.3.0-i686-windows\examples\cxx\tree\hello\hello.hxx(42): fatal error > C1083: Cannot open include file: 'xsd/cxx/config.hxx': No such file or > directory You need to add the libxsd path to the VC++ Include Directories list, as described in the README file that comes with the XSD package. Boris From boris at codesynthesis.com Fri Jan 4 06:16:01 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Jan 4 05:26:44 2013 Subject: [xsd-users] Re: The results of your email commands In-Reply-To: References: Message-ID: Hi Mallibabu, In the future please keep your replies CC'ed to the xsd-users mailing list as discussed in the posting guidelines: http://www.codesynthesis.com/support/posting-guidelines.xhtml Mallibabu karra writes: > 4>driver.obj : error LNK2001: unresolved external symbol > "__declspec(dllimport) public: static wchar_t const * const > xercesc_3_1::XMLUni::fgXercesUserAdoptsDOMDocument" > (__imp_?fgXercesUserAdoptsDOMDocument@XMLUni@xercesc_3_1@@2QB_WB) This error normally means that a wrong Xerces-C++ library is being linked. Make sure that you have your VC++ Library Directories entry for Xerecs-C++ (again, refer to the README file for details) point to the location where the Xerecs-C++ library (xerces-c_3D.lib) is located. Also make sure it is for the correct version of VC++ and is not built as a static library. The easiest way to make sure you are using the correct library is to download the pre-built package for your version of VC++ from the Xerces-C++ download page: http://xerces.apache.org/xerces-c/download.cgi Boris From owagh at tower-research.com Mon Jan 7 07:25:14 2013 From: owagh at tower-research.com (Omkar Wagh) Date: Mon Jan 7 07:11:52 2013 Subject: [xsd-users] Make suitable dependency generation In-Reply-To: References: <50C0FFC2.7010200@tower-research.com> <50C24CF3.5010907@tower-research.com> Message-ID: <50EABEAA.2010908@tower-research.com> Hi Apologies, I've been on vacation. I'm using rhel5. Omkar On 12/19/2012 03:46 AM, Boris Kolpackov wrote: > Hi Omkar, > > Omkar Wagh writes: > >> I'd be happy to test it in a pre-release version! > Ok, I've implemented this feature and it is ready to try. Can you let > me know which platform you are using so that I can build you a pre- > release? > > Boris From boris at codesynthesis.com Mon Jan 7 10:53:46 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Jan 7 10:03:33 2013 Subject: [xsd-users] Make suitable dependency generation In-Reply-To: <50EABEAA.2010908@tower-research.com> References: <50C0FFC2.7010200@tower-research.com> <50C24CF3.5010907@tower-research.com> <50EABEAA.2010908@tower-research.com> Message-ID: Omkar Wagh writes: > I'm using rhel5. Here you go: http://codesynthesis.com/~boris/tmp/xsd/xsd-4.0.0.a11-x86_64-linux-gnu.tar.bz2 Citing the NEWS file: "New option, --generate-dep, triggers the generation of the make dependency file (.d) for the generated C++ files. Other options controlling dependency generation are: --dep-phony, --dep-target, --dep-suffix, and --dep-regex. For details, refer to the XSD compiler command line manual (man pages)." Boris From videohead at mail.com Mon Jan 7 14:28:14 2013 From: videohead at mail.com (Olumide) Date: Tue Jan 8 09:29:39 2013 Subject: [xsd-users] Using xsd commercially in-house Message-ID: <50EB21CE.2090003@mail.com> Hello, Can xsd be used commercially in-house _solely_ to generate C++ files? The runtime library will not be linked with our codebase in anyway. Regards, - Olumide From boris at codesynthesis.com Tue Jan 8 10:37:30 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Jan 8 09:47:04 2013 Subject: [xsd-users] Using xsd commercially in-house In-Reply-To: <50EB21CE.2090003@mail.com> References: <50EB21CE.2090003@mail.com> Message-ID: Hi Olumide, Olumide writes: > Can xsd be used commercially in-house _solely_ to generate C++ files? Yes, you can use XSD (including generating C++ files and linking to the XSD runtime) without having to publish your source code under the GPLv2 provided you do not distribute your application to any third party (which is what I believe you mean by "in-house"). > The runtime library will not be linked with our codebase in anyway. The generated code is quite useless without the runtime. The only use case I could think of is using the generated code as some kind of a test case for a static analysis tool or some such. But, as I mentioned above, you can link to the runtime if you need to. Boris From videohead at mail.com Tue Jan 8 10:30:00 2013 From: videohead at mail.com (Olumide) Date: Tue Jan 8 10:16:31 2013 Subject: [xsd-users] Using xsd commercially in-house In-Reply-To: References: <50EB21CE.2090003@mail.com> Message-ID: <50EC3B78.2030005@mail.com> On 08/01/2013 15:37, Boris Kolpackov wrote: >> Can xsd be used commercially in-house _solely_ to generate C++ files? > > Yes, you can use XSD (including generating C++ files and linking to the > XSD runtime) without having to publish your source code under the GPLv2 > provided you do not distribute your application to any third party (which > is what I believe you mean by "in-house"). > > >> The runtime library will not be linked with our codebase in anyway. > > The generated code is quite useless without the runtime. The only use > case I could think of is using the generated code as some kind of a > test case for a static analysis tool or some such. But, as I mentioned > above, you can link to the runtime if you need to. Here's what we need to do. Given an XML "config" file 3200 6400 12800 defining the attributes of an object, we would like to output the following C++ header and implementation files /* C++ Header File */ namespace ACME { class Gizmo { public: typedef std::vector Frequency; Frequency initializeFrequency(); // ideally, private static const Frequency m_frequency; static const bool m_supportsImages = false; static const unsigned m_deviceMemory = 128; static const std::string name(); }; } /* C++ implementation file */ namespace ACME { const Gizmo::m_frequency = Gizmo::initializeFrequency(); Frequency Gizmo::initializeFrequency() { Frequency freq; freq.push_back( 3200 ); freq.push_back( 6400 ); freq.push_back( 12800 ); return freq; } const std::string Gizmo::name() { return "ACME::Gizmo"; } } As you can see the generated code is self contained. And yes the code generated will be shipped. Regards, - Olumide From boris at codesynthesis.com Wed Jan 9 09:35:51 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Jan 9 08:45:11 2013 Subject: [xsd-users] Re: Pugixml In-Reply-To: References: Message-ID: Hi Wesley, Wesley Peters writes: > Have you ever considered extending XSD to be able to use pugixml as > the underlying xml implementation? We have used pugixml for a couple > of projects here, and it seems to have a fair amount of capability and > is super fast. For anyone who doesn't need a validating engine, pugixml > is worth considering, and it would make a great addition to XSD. I get such questions from time to time so I've CC'ed xsd-users to my reply. The short answer to your question is no, there are no plans. The long answer is two-part: 1. XSD (C++/Tree, really) derives a lot of its power and flexibility from tight integration with Xerces-C++. Things like DOM association, DOM pre/post-processing (i.e., "fixing up" broken XML to make it conform to the schema), etc. So while the parser you suggested also seem to provide some kind of a DOM API, it will be a challange to support switching API from Xerces-C++ ro pugixml. 2. A lot of the new "super fast" XML parsers out there are not real XML parsers, that is, they don't conform to the XML 1.0 spec. See this blog post I wrote on the subject: http://www.codesynthesis.com/~boris/blog/2008/05/19/real-xml-parser/ While I haven't tested pugixml (there seems to be a new one every couple of months), I am pretty certain it is non-conforming. While you may say that its level of XML support is sufficient for your needs, keep in mind that XSD is a general-purpose tool used by many people in different scenarios. We don't want to end up explaining why XSD cannot handle perfectly valid XML over and over again. Plus, if you are looking for a smaller/faster equivalent to the XSD+Xerces-C++ combo, take a look at XSD/e: http://www.codesynthesis.com/products/xsde/ Inside it uses Expat as the XML parser, which is one of the fastest (if not the fastest) *fully conforming* XML 1.0 parser. Boris From tedquan at gmail.com Tue Jan 15 01:02:43 2013 From: tedquan at gmail.com (Ted Quan) Date: Tue Jan 15 04:37:22 2013 Subject: [xsd-users] error: unable to generate the test driver without a unique document root Message-ID: Hi Boris, I try the following command parser/serializer. I got the following error: xsde cxx-serializer --generate-inline --generate-empty-impl --generate-test-driver --force-overwrite ElectronicReceiptSubmit.xsd ElectronicReceiptSubmit.xsd: error: unable to generate the test driver without a unique document root ElectronicReceiptSubmit.xsd: info: use --root-element-* options to specify the document root xsde cxx-parser --generate-inline --generate-print-impl --generate-test-driver --force-overwrite ElectronicReceiptSubmit.xsd ElectronicReceiptSubmit.xsd: error: unable to generate the test driver without a unique document root ElectronicReceiptSubmit.xsd: info: use --root-element-* options to specify the document root I use xsde version 3.2.0 on linux (i686). Could you shred some light? Best regards, Ted From tedquan at gmail.com Tue Jan 15 01:11:18 2013 From: tedquan at gmail.com (Ted Quan) Date: Tue Jan 15 04:37:22 2013 Subject: [xsd-users] error: unable to generate the test driver without a unique document root In-Reply-To: References: Message-ID: FYI include XSD files On Tue, Jan 15, 2013 at 1:02 AM, Ted Quan wrote: > Hi Boris, > > I try the following command parser/serializer. I got the following error: > > xsde cxx-serializer > --generate-inline --generate-empty-impl --generate-test-driver --force-overwrite ElectronicReceiptSubmit.xsd > > ElectronicReceiptSubmit.xsd: error: unable to generate the test driver > without a unique document root > ElectronicReceiptSubmit.xsd: info: use --root-element-* options to specify > the document root > > xsde cxx-parser > --generate-inline --generate-print-impl --generate-test-driver --force-overwrite ElectronicReceiptSubmit.xsd > > ElectronicReceiptSubmit.xsd: error: unable to generate the test driver > without a unique document root > ElectronicReceiptSubmit.xsd: info: use --root-element-* options to specify > the document root > > I use xsde version 3.2.0 on linux (i686). > Could you shred some light? > > Best regards, > Ted > -------------- next part -------------- A non-text attachment was scrubbed... Name: ElectronicReceiptSubmit.xsd Type: application/octet-stream Size: 10210 bytes Desc: not available Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20130115/679e888e/ElectronicReceiptSubmit-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: ElectronicReceiptType.xsd Type: application/octet-stream Size: 32940 bytes Desc: not available Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20130115/679e888e/ElectronicReceiptType-0001.obj From for_usenet at yahoo.com Fri Jan 18 10:47:49 2013 From: for_usenet at yahoo.com (vinai) Date: Fri Jan 18 10:33:00 2013 Subject: [xsd-users] how to compile utilizing a non-standard location of xerces Message-ID: <1358524069.99645.YahooMailClassic@web163804.mail.gq1.yahoo.com> Hi All, We are building an application that has XSD as a dependency, and we'd like to distribute to others. Our application is to be installed onto a linux controller PC where it would be best not to touch software installed in system locations. We are trying to package up all dependencies into a single directory that would contain all necessary additional software, and could be installed to a location that does not require system privileges. This directory would have its own bin, lib, include, etc directories, and the systems we are targeting do not have installations of XSD or xerces-c ... We built and installed xerces-c 3.1.1 in this non-system locale, but have gotten stuck on trying to compile xsd to see and use this location. We've downloaded xsd-3.3.0-2+dep.tar.bz2, which did not have xerces-c. So we've tweaked various makefiles in the different locations to try to get things to build, but we are stuck where xsd cannot build because the compiler cannot resolve references to components of xerces-c. We were wondering where is the best place to tell the build process about the non-standard location of xerces-c so the compilation would complete. Thank you. From for_usenet at yahoo.com Fri Jan 18 10:48:03 2013 From: for_usenet at yahoo.com (vinai) Date: Fri Jan 18 10:33:15 2013 Subject: [xsd-users] how to compile utilizing a non-standard location of xerces Message-ID: <1358524083.34494.YahooMailClassic@web163806.mail.gq1.yahoo.com> Hi All, We are building an application that has XSD as a dependency, and we'd like to distribute to others. Our application is to be installed onto a linux controller PC where it would be best not to touch software installed in system locations. We are trying to package up all dependencies into a single directory that would contain all necessary additional software, and could be installed to a location that does not require system privileges. This directory would have its own bin, lib, include, etc directories, and the systems we are targeting do not have installations of XSD or xerces-c ... We built and installed xerces-c 3.1.1 in this non-system locale, but have gotten stuck on trying to compile xsd to see and use this location. We've downloaded xsd-3.3.0-2+dep.tar.bz2, which did not have xerces-c. So we've tweaked various makefiles in the different locations to try to get things to build, but we are stuck where xsd cannot build because the compiler cannot resolve references to components of xerces-c. We were wondering where is the best place to tell the build process about the non-standard location of xerces-c so the compilation would complete. Thank you. From boris at codesynthesis.com Fri Jan 18 11:39:38 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Jan 18 10:46:51 2013 Subject: [xsd-users] how to compile utilizing a non-standard location of xerces In-Reply-To: <1358524069.99645.YahooMailClassic@web163804.mail.gq1.yahoo.com> References: <1358524069.99645.YahooMailClassic@web163804.mail.gq1.yahoo.com> Message-ID: Hi, Please don't post multiple copies of the same email. One is sufficient. vinai writes: > We built and installed xerces-c 3.1.1 in this non-system locale, > but have gotten stuck on trying to compile xsd to see and use > this location. We've downloaded xsd-3.3.0-2+dep.tar.bz2, which > did not have xerces-c. So we've tweaked various makefiles in the > different locations to try to get things to build, but we are > stuck where xsd cannot build because the compiler cannot resolve > references to components of xerces-c. You don't need to modify any makefiles in order to specify the alternative Xerces-C++ location. As described in the README file in xsd+dep package, the build system recognizes a number of make variables, including CPPFLAGS and LDFLAGS. Those should be used to specify the Xerces-C++ header (CPPFLAGS) and library location. For example, if you installed Xerces-C++ into /opt/xerces (so that headers are in /opt/xerces/include and libraries are in /opt/xerces/lib), then the command line would look like this: make CPPFLAGS=-I/opt/xerces/include LDFLAGS=-L/opt/xerces/lib Boris From for_usenet at yahoo.com Fri Jan 18 11:49:41 2013 From: for_usenet at yahoo.com (vinai) Date: Fri Jan 18 12:34:20 2013 Subject: [xsd-users] how to compile utilizing a non-standard location of xerces In-Reply-To: Message-ID: <1358527781.65072.YahooMailClassic@web163801.mail.gq1.yahoo.com> --- On Fri, 1/18/13, Boris Kolpackov wrote: > vinai writes: > >> We built and installed xerces-c 3.1.1 in this non-system locale, >> but have gotten stuck on trying to compile xsd to see and use >> this location. We've downloaded xsd-3.3.0-2+dep.tar.bz2, which >> did not have xerces-c. So we've tweaked various makefiles in the >> different locations to try to get things to build, but we are >> stuck where xsd cannot build because the compiler cannot resolve >> references to components of xerces-c. > > You don't need to modify any makefiles in order to specify the > alternative Xerces-C++ location. As described in the README file > in xsd+dep package, the build system recognizes a number of make > variables, including CPPFLAGS and LDFLAGS. Those should be used > to specify the Xerces-C++ header (CPPFLAGS) and library location. > > For example, if you installed Xerces-C++ into /opt/xerces (so > that headers are in /opt/xerces/include and libraries are in > /opt/xerces/lib), then the command line would look like this: > > make CPPFLAGS=-I/opt/xerces/include LDFLAGS=-L/opt/xerces/lib > > Boris Thank you Boris. That worked perfectly. My apologies for being so thick-headed. It was definitely a case of missing something obvious after staring at this and related things for too long. Vinai From charlesegrant at me.com Tue Jan 22 19:54:39 2013 From: charlesegrant at me.com (Charles Grant) Date: Wed Jan 23 02:25:52 2013 Subject: [xsd-users] Specifying location of boost when building from all-in-one package Message-ID: <331EE804-E48E-4FAD-9DED-F412435DF7CE@me.com> Hi, I'm building XSD from the all-in-once package xsd-3.3.0-2+dep.tar.bz2. My system has multiple copies of Boost installed. The XSD build finds the one in /usr/include and /usr/lib/lib64 and uses that. I'd like to direct the XSD build to use a different one. Is there a 'make' switch or environment variable I can set to control this? Thanks, Charles From boris at codesynthesis.com Wed Jan 23 07:36:19 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Jan 23 06:42:26 2013 Subject: [xsd-users] Specifying location of boost when building from all-in-one package In-Reply-To: <331EE804-E48E-4FAD-9DED-F412435DF7CE@me.com> References: <331EE804-E48E-4FAD-9DED-F412435DF7CE@me.com> Message-ID: Hi Charles, Charles Grant writes: > I'm building XSD from the all-in-once package xsd-3.3.0-2+dep.tar.bz2. > My system has multiple copies of Boost installed. The XSD build finds > the one in /usr/include and /usr/lib/lib64 and uses that. I'd like to > direct the XSD build to use a different one. Is there a 'make' switch > or environment variable I can set to control this? Here is my reply from a few days ago to pretty much the same question: http://www.codesynthesis.com/pipermail/xsd-users/2013-January/003814.html Boris From charlesegrant at me.com Wed Jan 23 14:54:54 2013 From: charlesegrant at me.com (Charles Grant) Date: Thu Jan 24 02:03:55 2013 Subject: [xsd-users] Specifying location of boost when building from all-in-one package In-Reply-To: References: <331EE804-E48E-4FAD-9DED-F412435DF7CE@me.com> Message-ID: Hi Boris, On Jan 23, 2013, at 4:36 AM, Boris Kolpackov wrote: > > Here is my reply from a few days ago to pretty much the same question: > > http://www.codesynthesis.com/pipermail/xsd-users/2013-January/003814.html > Thanks for your quick response! I believe I've already tried that. My make command line is: make \ verbose=1 \ CPPFLAGS="-I $HOME/projects/crux-percolator/src/external/include" \ LDFLAGS="-L $HOME/projects/crux-percolator/src/external/lib" The build does find the Xerces-C library in those directories, but it still uses the copy of Boost from /usr. The first reference to the Boost libraries in the make output is: echo "`cat /net/noble/vol1/home/cegrant/xsd-3.3.0-2+dep.cluster/libfrontend-elements/frontend-elements/frontend-elements.l` `cat /net/noble/vol1/home/cegrant/xsd-3.3.0-2+dep.cluster/libcult/cult/cult.l` /net/noble/vol1/home/cegrant/projects/crux-percolator/src/external/lib/libxerces-c.a /usr/lib64/libboost_filesystem.so /usr/lib64/libboost_system.so" | xargs -n 1 echo >>/net/noble/vol1/home/cegrant/xsd-3.3.0-2+dep.cluster/libxsd-frontend/xsd-frontend/xsd-frontend.l which seems to confirm that the build is finding the correct Xerces libraries, but not the correct Boost libraries. Interestingly, when I build XSD on another system that doesn't have Boost installed in /usr, and then the XSD build does find the copy of Boost in the specified directories. Thanks for your help and I would appreciate any suggestions you might have. Charles From boris at codesynthesis.com Thu Jan 24 09:26:41 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Jan 24 08:32:32 2013 Subject: [xsd-users] Specifying location of boost when building from all-in-one package In-Reply-To: References: <331EE804-E48E-4FAD-9DED-F412435DF7CE@me.com> Message-ID: Hi Charles, Charles Grant writes: > make \ > verbose=1 \ > CPPFLAGS="-I $HOME/projects/crux-percolator/src/external/include" \ > LDFLAGS="-L $HOME/projects/crux-percolator/src/external/lib" > > The build does find the Xerces-C library in those directories, but > it still uses the copy of Boost from /usr. Can you verify a few things: 1. You are doing a full rebuild. 2. Can you check if the required Boost libraries are actually in $HOME/projects/crux-percolator/src/external/lib? Oftentimes, Boost library names include suffixes that contain various information like compiler name and version, etc. If that's the case, then you will need to use the BOOST_LIB_SUFFIX variable to specify the suffix. Boris From cegrant at uw.edu Thu Jan 24 22:08:52 2013 From: cegrant at uw.edu (Charles Grant) Date: Thu Jan 24 21:53:37 2013 Subject: [xsd-users] Specifying location of boost when building from all-in-one package In-Reply-To: References: <331EE804-E48E-4FAD-9DED-F412435DF7CE@me.com> Message-ID: Hi Boris, On Jan 24, 2013, at 6:26 AM, Boris Kolpackov wrote: > > Can you verify a few things: > > 1. You are doing a full rebuild. I did 'make clean' between builds. Is that sufficient? > 2. Can you check if the required Boost libraries are actually in > $HOME/projects/crux-percolator/src/external/lib? > > Oftentimes, Boost library names include suffixes that contain > various information like compiler name and version, etc. If > that's the case, then you will need to use the BOOST_LIB_SUFFIX > variable to specify the suffix. The libraries are there. The script that builds boost for us also adds links that remove the suffixes. The libraries are there with both names. For example: /net/noble/vol1/home/cegrant/projects/crux-percolator/src/external/lib/libboost_filesystem-gcc46-mt-s.a /net/noble/vol1/home/cegrant/projects/crux-percolator/src/external/lib/libboost_filesystem-mt-s.a@ /net/noble/vol1/home/cegrant/projects/crux-percolator/src/external/lib/libboost_filesystem.a@ On the problematic system the boost libraries in /usr/lib/lib64 don't have the suffix. Interestingly enough if I set BOOST_LIB_SUFFIX=--gcc46-mt-s the XSD build no longer finds the library in /usr/lib/lib64, and does find the correct library in /net/noble/vol1/home/cegrant/projects/crux-percolator/src/external/lib Unfortunately that doesn't provide a solution for us. All of this is all in service of distributing our source to users, and we can't rely on the libraries in /usr/lib/lib64 not having suffixes. It really looks like the XSD build is checking some standard library locations before it checks the ones in the LDFLAGS. Many thanks, Charles From Arul.Prakash2 at rsa.com Fri Jan 25 04:10:08 2013 From: Arul.Prakash2 at rsa.com (Prakash, Arul) Date: Fri Jan 25 07:03:34 2013 Subject: [xsd-users] Extracting data between xml tags Message-ID: <0DB3CF5C512BBD4FA7E3A8ECD8FE7352149EA93FAC@MX26A.corp.emc.com> Hi, I have this part of the schema The corresponding c++ code generated is class ContextType: public ::xml_schema::type { public: // ID // typedef ::xml_schema::string ID_type; typedef ::xsd::cxx::tree::optional< ID_type > ID_optional; typedef ::xsd::cxx::tree::traits< ID_type, char > ID_traits; const ID_optional& ID () const; ID_optional& ID (); void ID (const ID_type& x); void ID (const ID_optional& x); void ID (::std::auto_ptr< ID_type > p); // Constructors. // ContextType (); ContextType (const ::xercesc::DOMElement& e, ::xml_schema::flags f = 0, ::xml_schema::container* c = 0); ContextType (const ContextType& x, ::xml_schema::flags f = 0, ::xml_schema::container* c = 0); virtual ContextType* _clone (::xml_schema::flags f = 0, ::xml_schema::container* c = 0) const; virtual ~ContextType (); // Implementation. // protected: void parse (::xsd::cxx::xml::dom::parser< char >&, ::xml_schema::flags); protected: ID_optional ID_; }; My question is how can I construct a xml fragment like this < Sample ID="97612934">this is a string My current code looks like this CommonAPI::authentication::ContextType::ID_type sample_ID_type("97612934"); CommonAPI::authentication::ContextType sample_type; sample _type.ID(sample_ID_type); But I don't know how to set the value "this is a string" between the tags. Any pointers would be helpful. Thanks Arul From boris at codesynthesis.com Fri Jan 25 08:31:39 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Jan 25 07:37:19 2013 Subject: [xsd-users] Specifying location of boost when building from all-in-one package In-Reply-To: References: <331EE804-E48E-4FAD-9DED-F412435DF7CE@me.com> Message-ID: Hi Charles, Charles Grant writes: > I did 'make clean' between builds. Is that sufficient? Yes, that should be sufficient. > The libraries are there. > > [...]/libboost_filesystem.a@ > > > It really looks like the XSD build is checking some standard library > locations before it checks the ones in the LDFLAGS. Ok, I think I know what's going on here. GNU make 3.81 and earlier has broken library search path order in that it would first search in all the directories (both user-supplied and system) for .so and then for .a. This is in contrast to how ld works. That is, it examines each directory first for .so and then for .a. If you are using make 3.81, then this would explain why the build system picks up libboost_filesystem.so from /usr/lib instead of libboost_filesystem.a from your custom directory. There are two ways to fix this: 1. I've fixed the broken search order in make 3.82 so if you can upgrade, then that should fix your problem. 2. If you cannot upgrade, then the only way I can see to work around this (other than modifying the makefiles) is to disable search for shared libraries altogether: make .LIBPATTERNS=lib%.a Note that in this case Xerces-C++ will also have to be built as a static library. You may also have to add some extra libraries (e.g., -lpthread) with the LIBS variable. Boris From boris at codesynthesis.com Fri Jan 25 08:48:41 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Jan 25 07:54:20 2013 Subject: [xsd-users] Extracting data between xml tags In-Reply-To: <0DB3CF5C512BBD4FA7E3A8ECD8FE7352149EA93FAC@MX26A.corp.emc.com> References: <0DB3CF5C512BBD4FA7E3A8ECD8FE7352149EA93FAC@MX26A.corp.emc.com> Message-ID: Hi Arul, Prakash, Arul writes: > > > > > [...] > > My question is how can I construct a xml fragment like this > < Sample ID="97612934">this is a string Your type has mixed content which requires using DOM to access/modify the data. Note also that in this particular case there is no good reason for using mixed content. If you can change your schema, then a much cleaner variant that achieves the same semantics would be: It will also be much easier to use in C++: ContextType x ("this is a string"); x.ID ("97612934"); If you cannot change your schema and have to use the type with mixed content, then you will need to use type customization and DOM to access the text data. See the examples/cxx/tree/custom/mixed example for more information on how to do this. Boris From fred.kastner at emc.com Fri Jan 25 09:00:38 2013 From: fred.kastner at emc.com (Kastner, Fred) Date: Fri Jan 25 09:31:42 2013 Subject: [xsd-users] Xsd:list Message-ID: <45B07E45E230D540A50AA39E64B6C5A6016FCBA8A4@MX45A.corp.emc.com> Hi all, I am new to XSD and I need some help. I have the following in my xsd file: I want to create a "list type" and I tried to use: I compile using the command: xsd cxx-tree --generate-serialization prof.xsd I get the error: base type 'profile_t' not found in 'proflist_t' definition How can I solve the problem? Regards, -------------------------------------------------------------- Fred Kastner fred.kastner@emc.com EMC,Inc. Phone 508-249-2110 176 South St. Hopkinton, MA 01748 From boris at codesynthesis.com Fri Jan 25 10:29:18 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Jan 25 09:34:55 2013 Subject: [xsd-users] Xsd:list In-Reply-To: <45B07E45E230D540A50AA39E64B6C5A6016FCBA8A4@MX45A.corp.emc.com> References: <45B07E45E230D540A50AA39E64B6C5A6016FCBA8A4@MX45A.corp.emc.com> Message-ID: Hi Fred, Kastner, Fred writes: > > > [...] > > > > I want to create a "list type" and I tried to use: > > > > xsd:list is a space-separated list of itemType values. As a result (per the XML Schema spec), you can only use simple types as the list item types. Your prof_t is a complex type with nested elements, etc. Boris From cegrant at uw.edu Fri Jan 25 15:51:41 2013 From: cegrant at uw.edu (Charles Grant) Date: Fri Jan 25 15:36:14 2013 Subject: [xsd-users] Specifying location of boost when building from all-in-one package In-Reply-To: References: <331EE804-E48E-4FAD-9DED-F412435DF7CE@me.com> Message-ID: <8A253DF4-BC16-443E-9A56-A006D3B36F36@uw.edu> Hi Boris, On Jan 25, 2013, at 5:31 AM, Boris Kolpackov wrote: > 2. If you cannot upgrade, then the only way I can see to work around > this (other than modifying the makefiles) is to disable search for > shared libraries altogether: > > make .LIBPATTERNS=lib%.a > > Note that in this case Xerces-C++ will also have to be built as > a static library. You may also have to add some extra libraries > (e.g., -lpthread) with the LIBS variable. As it happens we were already doing a building static libraries for Xerces-C++, so this does the trick for us. Many thanks! We really appreciate your help. Charles From adam at kde.org Sat Jan 26 13:41:42 2013 From: adam at kde.org (Till Adam) Date: Sun Jan 27 08:57:29 2013 Subject: [xsd-users] Bug: failure to convert string to int Message-ID: <2944999.8nGvGK3roT@till.local> Heya, I seem to have stumbled upon a rather low level bug in libxsd on OSX Lion. Basically the date_time parsing fails reliably because string to number conversion via zs_istream does. I've narrowed it down to a rather minimal test case which you can find here: http://www.kdab.com/~till/xsd-bug.tar.gz The same test case works fine on Linux, so I rather suspect this is a libc issue on Mac OSX, possibly a 64bit only one. I did try both clang and g++, no difference. Some version info: xsd-3.3.0-i686-macosx i686-apple-darwin11-llvm-g++-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) Apple clang version 4.1 (tags/Apple/clang-421.11.66) (based on LLVM 3.1svn) Target: x86_64-apple-darwin11.4.2 Thread model: posix Mac OS X Lion 10.7.5 (11G63) Please keep me in CC, I am not subscribed. Cheers, Till From boris at codesynthesis.com Mon Jan 28 08:34:45 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Jan 28 07:39:43 2013 Subject: [xsd-users] Bug: failure to convert string to int In-Reply-To: <2944999.8nGvGK3roT@till.local> References: <2944999.8nGvGK3roT@till.local> Message-ID: Hi Till, Till Adam writes: > I seem to have stumbled upon a rather low level bug in libxsd on OSX Lion. I tried to reproduce the bug on 10.8 and 10.3 (I don't have access to 10.7) without any success. I tried 32/64, g++/clang++, optimized/non- optimized combinations and they all seem to work fine. It is also not clear what happens when the test fails. Does it crash? Does it print a wrong value? If it crashes, would you be able to get the stack trace? Thanks Boris From adam at kde.org Mon Jan 28 09:03:49 2013 From: adam at kde.org (Till Adam) Date: Mon Jan 28 08:56:49 2013 Subject: [xsd-users] Bug: failure to convert string to int In-Reply-To: References: <2944999.8nGvGK3roT@till.local> Message-ID: <6F6001EB-54B3-4A07-A6D4-565918FEE0F5@kde.org> Heya Boris, thanks for checking out the bug. On Jan 28, 2013, at 2:34 PM, Boris Kolpackov wrote: > Till Adam writes: > >> I seem to have stumbled upon a rather low level bug in libxsd on OSX Lion. > > I tried to reproduce the bug on 10.8 and 10.3 (I don't have access to > 10.7) without any success. I tried 32/64, g++/clang++, optimized/non- > optimized combinations and they all seem to work fine. Weird, but encouraging, at least as far as 10.8 is concerned. I'll see if I can test on that. > It is also not clear what happens when the test fails. Does it crash? > Does it print a wrong value? If it crashes, would you be able to get > the stack trace? No, it does not crash, it simply prints 0, for the value of year. It seems to magically find an empty buffer, from what I can tell. I'll see if I can get more information. If someone else could confirm that it fails for them on 10.7, I would be grateful. Cheers, Till From Ulf.Haga at gyros.com Thu Jan 31 04:22:23 2013 From: Ulf.Haga at gyros.com (Haga, Ulf) Date: Thu Jan 31 04:25:42 2013 Subject: [xsd-users] XSD compiler generate bad constructor. Ambiguous call to overloaded function Message-ID: <5740182C3A13F84CB618CFD727885561040D3961@VIEX01SE.ad-gyrosmicro.com> Hi! Our company Gyros has bought a license. If you can't find it let me know. We problem is that the XSD compiler generate a bad constructor. XSD: XSD Compiler generate: ... CInstrumentConfig (const ::xercesc::DOMElement& e, ::xml_schema::flags f = 0, ::xml_schema::container* c = 0); .. Our C++ code: CInstrumentConfig::GyrolabContent_type gxmlGyrolab(*myDomElement); Problem: Visual C++ 10 compiler gives this error: GyrolabContent::GyrolabContent' : ambiguous call to overloaded function The Visual C++ 10 compiler can't decide to use gxmlGyrolab(*myDomElement) or gxmlGyrolab(*myDomElement,0,0); There is no compiler error with this code gxmlGyrolab(*myDomElement,0,0); xsd.exe cxx-tree --generate-serialization -show -sloc -name space-map http://gyros.com/gyrosxml/12/03=gyrosxml_12_03 -output -dir C:\GSS\WebServiceC++\Api\src --generate-wildcard instrument_commands.xsd Regards Ulf Haga From boris at codesynthesis.com Thu Jan 31 07:09:50 2013 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Jan 31 06:14:07 2013 Subject: [xsd-users] XSD compiler generate bad constructor. Ambiguous call to overloaded function In-Reply-To: <5740182C3A13F84CB618CFD727885561040D3961@VIEX01SE.ad-gyrosmicro.com> References: <5740182C3A13F84CB618CFD727885561040D3961@VIEX01SE.ad-gyrosmicro.com> Message-ID: Hi Ulf, Haga, Ulf writes: > > > > > > > > Yes, in this special case (i.e., a type with a single wildcard and no other required elements or attributes), XSD-generated constructors are ambiguous: GyrolabContent (const ::xercesc::DOMElement&); GyrolabContent (const ::xercesc::DOMElement& e, ::xml_schema::flags f = 0, ::xml_schema::container* c = 0); The first constructor is meant to set the wildcard while the second is the standard parsing constructor. Unfortunately, there doesn't seem to be a good way to fix this. So in this special case you can use the following work around: 1. Generate the default constructor with the --generate-default-ctor 2. Initialize the element in two steps: const DOMElement& e = ... GyrolabContent x; x.any (e); Note also that calling the second constructor does not have the same semantics. Thanks for reporting this! Boris