From boris at codesynthesis.com Tue May 1 11:10:49 2018 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue May 1 11:16:30 2018 Subject: [odb-users] Refer a persistent class from another persistent class, where both classes are implemented in different libraries In-Reply-To: <1525115929.168632961@f451.i.mail.ru> References: <1525115929.168632961@f451.i.mail.ru> Message-ID: ?????? ??????? writes: > I've encountered a linking problem in the following situation: > - persistent class 'A' is defined in 'moduleA' library > - persistent class 'B' is defined in 'moduleB' library and refers to 'A' > - both modules are built with dynamic multi-database support > > When I try to build a library with supporting database code for > 'moduleB' I get the following linker error: > > error LNK2019: unresolved external symbol "public: static class std::shared_ptr __cdecl odb::access::object_traits_impl::find(class odb::database &,unsigned __int64 const &)" (...) referenced in function "protected: class std::shared_ptr __cdecl odb::database::find_(unsigned __int64 const &)" (...) > > ODB compiler options for B.h compiling are (not all): > > [...] --export-symbol common:moduleB_EXPORT Provided that you have a similar export setup for the moduleA library and that you link moduleA to moduleB, it should work. Are you able to link moduleA to an executable that calls database::load() without unresolved symbols? Boris From shprotello at mail.ru Thu May 3 14:50:50 2018 From: shprotello at mail.ru (=?UTF-8?B?0KHQtdGA0LPQtdC5INCd0LjQutC+0L3QvtCy?=) Date: Thu May 3 14:56:46 2018 Subject: =?UTF-8?B?UmVbMl06IFtvZGItdXNlcnNdIFJlZmVyIGEgcGVyc2lzdGVudCBjbGFzcyBm?= =?UTF-8?B?cm9tIGFub3RoZXIgcGVyc2lzdGVudCBjbGFzcywgd2hlcmUgYm90aCBjbGFz?= =?UTF-8?B?c2VzIGFyZSBpbXBsZW1lbnRlZCBpbiBkaWZmZXJlbnQgbGlicmFyaWVz?= In-Reply-To: References: <1525115929.168632961@f451.i.mail.ru> Message-ID: <1525373450.314611326@f460.i.mail.ru> Hi Boris, I have the similar export setup for moduleA too, but with a different symbol defined: --export-symbol common:moduleA_EXPORT. If I link the modules with a shared library (or application) that uses both classes everything is OK. I've resolved the issue temporarily by adding necessary code from moduleA to moduleB. Thank you, Sergey >???????, 1 ??? 2018, 18:11 +03:00 ?? Boris Kolpackov < boris@codesynthesis.com >: > >?????? ??????? < shprotello@mail.ru > writes: > >> I've encountered a linking problem in the following situation: >> - persistent class 'A' is defined in 'moduleA' library >> - persistent class 'B' is defined in 'moduleB' library and refers to 'A' >> - both modules are built with dynamic multi-database support >> >> When I try to build a library with supporting database code for >> 'moduleB' I get the following linker error: >> >> error LNK2019: unresolved external symbol "public: static class std::shared_ptr __cdecl odb::access::object_traits_impl::find(class odb::database &,unsigned __int64 const &)" (...) referenced in function "protected: class std::shared_ptr __cdecl odb::database::find_(unsigned __int64 const &)" (...) >> >> ODB compiler options for B.h compiling are (not all): >> >> [...] --export-symbol common:moduleB_EXPORT > >Provided that you have a similar export setup for the moduleA library >and that you link moduleA to moduleB, it should work. > >Are you able to link moduleA to an executable that calls database::load () >without unresolved symbols? > > >Boris From mruess at gmail.com Fri May 4 04:03:47 2018 From: mruess at gmail.com (Matthias Ruess) Date: Fri May 4 11:20:09 2018 Subject: [odb-users] VS2017 In-Reply-To: References: Message-ID: Hi Boris, I know that it is hard to estimate when a software project is ready for shipping. But is it realistic to get the new ODB release by August? Keep up the great work, Matt On Tue, Dec 12, 2017 at 9:56 AM, Matthias Ruess wrote: > Thank you very much for the detailled answers - then I will wait until > spring 2018... > Cheers, Matt > > On Tue, Dec 12, 2017 at 8:17 AM, Boris Kolpackov > wrote: > >> Matthias Ruess writes: >> >> > I want to update my VS2013 projects to 2017 and have two questions: >> > Should ODB 2.4.0 compile with VS 2017 version 15.5? >> >> Yes, though I would recommend that you use the latest pre-release (we >> use[1] it ourselves with VS 15): >> >> https://codesynthesis.com/~boris/tmp/odb/pre-release/b.3/ >> >> >> > Will there be a new version of odb in the next 2 or 3 months or will it >> > take longer? >> >> This is the timeframe (i.e., early next year) we are aiming for but it >> may take longer. >> >> >> > Is the next version of libodb-mysql part of the vcpkg ports like >> > libodb-sqlite? >> >> The vcpkg package of libodb-sqlite was not done by us (in fact, this >> is the first time I am hearing about it) so can't say anything about >> libodb-mysql. >> >> Both will be (in fact, already are[2]) packaged for bpkg. And >> libodb-mysql will be usable with both MySQL and MariaDB client >> libraries (and even on Windows). >> >> [1] https://build2.org/ >> [2] https://stage.build2.org/?q=mysql >> >> Boris >> > > From odb at a-cunningham.com Fri May 4 17:47:23 2018 From: odb at a-cunningham.com (Andrew Cunningham) Date: Fri May 4 17:53:22 2018 Subject: [odb-users] VS2017 In-Reply-To: References: Message-ID: Hi Matthias, I use ODB 2.5b3 "pre-release" with VS 2017 and it works perfectly. It's a must have as 2.4.0 has a number of bugs that you might hit.... Andrew On Fri, May 4, 2018 at 1:03 AM, Matthias Ruess wrote: > Hi Boris, > > I know that it is hard to estimate when a software project is ready for > shipping. > But is it realistic to get the new ODB release by August? > > Keep up the great work, Matt > > > On Tue, Dec 12, 2017 at 9:56 AM, Matthias Ruess wrote: > > > Thank you very much for the detailled answers - then I will wait until > > spring 2018... > > Cheers, Matt > > > > On Tue, Dec 12, 2017 at 8:17 AM, Boris Kolpackov < > boris@codesynthesis.com> > > wrote: > > > >> Matthias Ruess writes: > >> > >> > I want to update my VS2013 projects to 2017 and have two questions: > >> > Should ODB 2.4.0 compile with VS 2017 version 15.5? > >> > >> Yes, though I would recommend that you use the latest pre-release (we > >> use[1] it ourselves with VS 15): > >> > >> https://codesynthesis.com/~boris/tmp/odb/pre-release/b.3/ > >> > >> > >> > Will there be a new version of odb in the next 2 or 3 months or will > it > >> > take longer? > >> > >> This is the timeframe (i.e., early next year) we are aiming for but it > >> may take longer. > >> > >> > >> > Is the next version of libodb-mysql part of the vcpkg ports like > >> > libodb-sqlite? > >> > >> The vcpkg package of libodb-sqlite was not done by us (in fact, this > >> is the first time I am hearing about it) so can't say anything about > >> libodb-mysql. > >> > >> Both will be (in fact, already are[2]) packaged for bpkg. And > >> libodb-mysql will be usable with both MySQL and MariaDB client > >> libraries (and even on Windows). > >> > >> [1] https://build2.org/ > >> [2] https://stage.build2.org/?q=mysql > >> > >> Boris > >> > > > > > From boris at codesynthesis.com Thu May 10 08:57:17 2018 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu May 10 08:57:33 2018 Subject: [odb-users] VS2017 In-Reply-To: References: Message-ID: Matthias Ruess writes: > I know that it is hard to estimate when a software project is ready for > shipping. But is it realistic to get the new ODB release by August? Don't think the "official"/final release, but something close to that and even the ability to build the ODB compiler yourself from source on Windows. Boris From finjulhich at gmail.com Fri May 11 09:38:33 2018 From: finjulhich at gmail.com (MM) Date: Fri May 11 09:38:59 2018 Subject: [odb-users] indirect relatioship between objects with std::vector> Message-ID: Hello, odb handles transparently point-to relationships (one way or bidirectional) like in the examples of employer/employee. My case is a little more complex than a direct pointer relationship. struct X {}; struct Y {}; struct Aelt { boost::variant elt_; }; struct A { std::vector elements_; }; using nstring = odb::nullable; #pragma db value(Aelt) definition #pragma db member(Aelt::elt_) transient #pragma db member(Aelt::X) virtual(nstring) get(...) set(...) //// can be NULL #pragma db member(Aelt::Y) virtual(nstring) get(...) set(...) //// can be NULL /// The getter and setter just stores the name of X or the name of Y #pragma db object(A) definition #pragma db member(A::elements_) This however does not store the X/Y objects themselves if they haven't been persisted. If I want to have odb persist/load Xs and Ys when I persist A instances, I would need to implement that myself in get(...) and set(...), but I feel I'd be going about that incorrectly. Can I leverage odb's transparent handling in this case? Rds, MM From c.sell at byterefinery.de Sat May 12 12:10:25 2018 From: c.sell at byterefinery.de (c.sell@byterefinery.de) Date: Sat May 12 12:10:58 2018 Subject: [odb-users] compile errors building odb 2.5 compiler Message-ID: <20180512161025.Horde.fHxdEGZt9xC8g3cmEDdMc5n@webmail.byterefinery.de> Hello, after my recent upgrade to fedorea 28 and gcc 8.0.1, the odb compiler was no longer working: cc1plus: error: cannot load plugin /usr/local/bin/../libexec/odb/odb.so /usr/local/bin/../libexec/odb/odb.so: undefined symbol: global_namespace I therefore decided to rebuild the compiler, using the 2.5.a11 and b4 pre-releases. However, after a successful ./configure, the 'make' yields compile errors: [byter@xps15 odb-2.5.0-b.4]$ make Making all in odb make[1]: Entering directory '/home/byter/work/odb/2.5/odb-2.5.0-b.4/odb' make all-am make[2]: Entering directory '/home/byter/work/odb/2.5/odb-2.5.0-b.4/odb' depbase=`echo cxx-lexer.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\ /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I'..' -I'..' -I/usr/lib/gcc/x86_64-redhat-linux/8/plugin/include -g -O2 -MT cxx-lexer.lo -MD -MP -MF $depbase.Tpo -c -o cxx-lexer.lo cxx-lexer.cxx &&\ mv -f $depbase.Tpo $depbase.Plo libtool: compile: g++ -DHAVE_CONFIG_H -I.. -I.. -I/usr/lib/gcc/x86_64-redhat-linux/8/plugin/include -g -O2 -MT cxx-lexer.lo -MD -MP -MF .deps/cxx-lexer.Tpo -c cxx-lexer.cxx -fPIC -DPIC -o .libs/cxx-lexer.o cxx-lexer.cxx: In member function ?virtual cpp_ttype cxx_pragma_lexer::next(std::__cxx11::string&, tree_node**)?: cxx-lexer.cxx:96:29: error: ?C_IS_RESERVED_WORD? was not declared in this scope if (*type_ == CPP_NAME && C_IS_RESERVED_WORD (*token_)) can anyone help? thanks, Christian From ratkaisut at gmail.com Mon May 14 05:15:07 2018 From: ratkaisut at gmail.com (Sten Kultakangas) Date: Mon May 14 05:15:43 2018 Subject: [odb-users] automatically detect abstract class instantiated from a template Message-ID: Hello The documentation provides the following example: #pragma db object abstract class base_common { ... #pragma db id auto unsigned long id; }; template class base: public base_common { ... T value; }; typedef base string_base; #pragma db object(string_base) abstract #pragma db object class derived: public string_base { ... }; The problem is that the string_base definition seems to be redundant and can induce problems with codebase maintainability. When writing new code it is easy to make a typo in those two lines which can create a hard to diagnose runtime error in some scenarios (my base class template uses dynamic_cast(this)). I'm considering making changes to the odb compiler making the above string_base definition unnecessary because it is possible to see that base inherits base_common which is defined as an abstract database object. Is there a reason why the current odb release candidate does not detect such condition and requires explicit definition of the parent class as an abstract database object ? The aim is to make the following definition possible without additional types: #pragma db object class derived: public base { ... }; Best regards, Sten Kultakangas From boris at codesynthesis.com Mon May 14 11:04:40 2018 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon May 14 11:05:10 2018 Subject: [odb-users] indirect relatioship between objects with std::vector> In-Reply-To: References: Message-ID: MM writes: > struct X {}; > struct Y {}; > > struct Aelt { > boost::variant elt_; > }; > struct A { > std::vector elements_; > }; > using nstring = odb::nullable; > > #pragma db value(Aelt) definition > #pragma db member(Aelt::elt_) transient > #pragma db member(Aelt::X) virtual(nstring) get(...) set(...) //// can be NULL > #pragma db member(Aelt::Y) virtual(nstring) get(...) set(...) //// can be NULL > /// The getter and setter just stores the name of X or the name of Y > > #pragma db object(A) definition > #pragma db member(A::elements_) > > This however does not store the X/Y objects themselves if they haven't > been persisted. > > If I want to have odb persist/load Xs and Ys when I persist A > instances, I would need to implement that myself in get(...) and > set(...), but I feel I'd be going about that incorrectly. While I am fuzzy on what exactly you are trying to achieve, if you want the object pointer/relationship functionality, then you will need to make Alert::X and Alert::Y object pointers. Boris From boris at codesynthesis.com Mon May 14 11:10:35 2018 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon May 14 11:11:05 2018 Subject: [odb-users] compile errors building odb 2.5 compiler In-Reply-To: <20180512161025.Horde.fHxdEGZt9xC8g3cmEDdMc5n@webmail.byterefinery.de> References: <20180512161025.Horde.fHxdEGZt9xC8g3cmEDdMc5n@webmail.byterefinery.de> Message-ID: c.sell@byterefinery.de writes: > after my recent upgrade to fedorea 28 and gcc 8.0.1, the odb compiler was no > longer working: These are the commits that make ODB compatible with GCC 8: https://git.codesynthesis.com/cgit/odb/odb/commit/?id=356630ced28f3101e8e2d88e3c52f8d3008515c7 https://git.codesynthesis.com/cgit/odb/odb/commit/?id=006bbc5748a8197d7874550cc9186545f1c55ad8 You can either try applying them to b.4 or just clone HEAD and build the latest & greatest. Boris From boris at codesynthesis.com Mon May 14 11:18:37 2018 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon May 14 11:19:07 2018 Subject: [odb-users] automatically detect abstract class instantiated from a template In-Reply-To: References: Message-ID: Sten Kultakangas writes: > I'm considering making changes to the odb compiler making the above > string_base definition unnecessary because it is possible to see that > base inherits base_common which is defined as an abstract > database object. > > Is there a reason why the current odb release candidate does not detect > such condition and requires explicit definition of the parent class as an > abstract database object ? Because dealing with unnamed entities sends complexity to the levels we have no capacity to handle. But you are, of course, welcome to try ;-). Boris From finjulhich at gmail.com Tue May 15 08:56:45 2018 From: finjulhich at gmail.com (MM) Date: Tue May 15 08:57:25 2018 Subject: [odb-users] indirect relatioship between objects with std::vector> Message-ID: On 14 May 2018 at 16:04, Boris Kolpackov wrote: > > MM writes: > > > struct X {}; > > struct Y {}; > > > > struct Aelt { > > boost::variant elt_; > > }; > > struct A { > > std::vector elements_; > > }; > > using nstring = odb::nullable; > > > > #pragma db value(Aelt) definition > > #pragma db member(Aelt::elt_) transient > > #pragma db member(Aelt::X) virtual(nstring) get(...) set(...) //// can be NULL > > #pragma db member(Aelt::Y) virtual(nstring) get(...) set(...) //// can be NULL > > /// The getter and setter just stores the name of X or the name of Y > > > > #pragma db object(A) definition > > #pragma db member(A::elements_) > > > > This however does not store the X/Y objects themselves if they haven't > > been persisted. > > > > If I want to have odb persist/load Xs and Ys when I persist A > > instances, I would need to implement that myself in get(...) and > > set(...), but I feel I'd be going about that incorrectly. > > While I am fuzzy on what exactly you are trying to achieve, if you > want the object pointer/relationship functionality, then you will > need to make Alert::X and Alert::Y object pointers. > > Boris Apologies, let me clarify a bit. "A" is a object which holds a collection of elements. These elements are of type "Aelt", short for "A element" Each element is a wrapper around either a pointer to X, or a pointer to Y, that is: the wrapper has a member that is a variant (pointer to X, pointer to Y) Obviously as things are, there's no "object pointer/relationship functionality" Let's start with an empty database, and imagine we have a transient instance of A, with a vector of 10 elements, each of a which wraps a variant that points to a X instance or a Y instance. The behavior that I'm looking for is that if I persist A, then, I would want my odb pragmas to persist the Xs and the Ys, but only if they are not persisted already. Similarly, if I load A, and the Xs and Ys instances are not loaded already, I'd want to load them as well. I am sorry: Is what I'm trying to achieve a little clearer? I followed the suggestion for storing the variant member as 2 nullable columns, 1 for X, 1 for Y. X and Y have string ids. Do I have to implement the get(...) and set(...) of those virtual columns in such a way that they check whether a X/Y instance exists before storing it or loading it? Thank you From boris at codesynthesis.com Thu May 17 11:43:40 2018 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu May 17 11:44:19 2018 Subject: [odb-users] indirect relatioship between objects with std::vector> In-Reply-To: References: Message-ID: MM writes: > The behavior that I'm looking for is that if I persist A, then, I > would want my odb pragmas to persist the Xs and the Ys, but only if > they are not persisted already. > > Similarly, if I load A, and the Xs and Ys instances are not loaded > already, I'd want to load them as well. Normally this kind of application-specific logic is best implemented using database operation callbacks and/or custom sessions. Boris From f_cellier at yahoo.fr Wed May 23 12:16:14 2018 From: f_cellier at yahoo.fr (francois cellier) Date: Wed May 23 12:17:23 2018 Subject: [odb-users] How to separate code in several dynamic libraries References: <1237832531.7825116.1527092174484.ref@mail.yahoo.com> Message-ID: <1237832531.7825116.1527092174484@mail.yahoo.com> Hello, On my project, I need to have binary code separated in several dynamic libraries regarding some criterion. In each library I have classes with specific odb pragma annotations. However there are some dependancies between the libraries. For example let's say that libA depends on libB. I succeeded into generating the schema for my complete model (libA and libB) in one sql file and that is fine. I also succeeded to generate the *.ixx, *.hxx and *.cxx files for the libB as it has no dependencies on external (to libB) classes that have odb pragma annotations. However I have trouble to generate the *.ixx, *.hxx and *.cxx files of the libA. I always have in the generated code of the libB classes and I would like to have only the code of the libA classes. The solution proposed here : https://www.codesynthesis.com/pipermail/odb-users/2015-October/002911.html does not seem to work for me. Even if I do not set the "definition" annotation, the code for the classes in libB is generated. Do you have any idea of how it should be done ? Thanks for your help, Fran?ois ? From boris at codesynthesis.com Thu May 24 12:27:24 2018 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu May 24 12:28:25 2018 Subject: [odb-users] How to separate code in several dynamic libraries In-Reply-To: <1237832531.7825116.1527092174484@mail.yahoo.com> References: <1237832531.7825116.1527092174484.ref@mail.yahoo.com> <1237832531.7825116.1527092174484@mail.yahoo.com> Message-ID: francois cellier writes: > Do you have any idea of how it should be done ? Show how (i.e., the ODB compiler command line) you generate the *-odb.* files for each library. From finjulhich at gmail.com Sat May 26 07:05:27 2018 From: finjulhich at gmail.com (MM) Date: Sat May 26 07:06:42 2018 Subject: [odb-users] indirect relatioship between objects with std::vector> Message-ID: On 17 May 2018 at 16:43, Boris Kolpackov wrote: > > MM writes: > > > The behavior that I'm looking for is that if I persist A, then, I > > would want my odb pragmas to persist the Xs and the Ys, but only if > > they are not persisted already. > > > > Similarly, if I load A, and the Xs and Ys instances are not loaded > > already, I'd want to load them as well. > > Normally this kind of application-specific logic is best implemented > using database operation callbacks and/or custom sessions. > > Boris Looking at 14.1.7. callback pragma from the manual, would this be like 1. for persisting: A would have a member function that gets called On pre_persist, the function would call persist() on the relevant X or Y object 2. for loading: A would have a member function that gets called On pre_load: the function would load() the relevant X or Y object Is it possible to have the called-back function not be a member function? Thanks MM From finjulhich at gmail.com Sun May 27 23:18:44 2018 From: finjulhich at gmail.com (MM) Date: Sun May 27 23:20:04 2018 Subject: [odb-users] indirect relatioship between objects with std::vector> Message-ID: On 26 May 2018 at 12:05, MM wrote: > On 17 May 2018 at 16:43, Boris Kolpackov wrote: >> >> MM writes: >> >> > The behavior that I'm looking for is that if I persist A, then, I >> > would want my odb pragmas to persist the Xs and the Ys, but only if >> > they are not persisted already. >> > >> > Similarly, if I load A, and the Xs and Ys instances are not loaded >> > already, I'd want to load them as well. >> >> Normally this kind of application-specific logic is best implemented >> using database operation callbacks and/or custom sessions. >> >> Boris > > Looking at 14.1.7. callback pragma from the manual, would this be like > > 1. for persisting: A would have a member function that gets called > On pre_persist, the function would call persist() on the relevant X or Y object > > 2. for loading: A would have a member function that gets called > On pre_load: the function would load() the relevant X or Y object > > Is it possible to have the called-back function not be a member function? > > Thanks > > MM It appears the callback pragma doesn't apply to value types, and it's just ignored. The odb compiler doesn't generate warnings for that. Can this pragma apply to value types too? MM From franchouze_llf at yahoo.fr Mon May 28 05:45:33 2018 From: franchouze_llf at yahoo.fr (francois cellier) Date: Mon May 28 05:50:57 2018 Subject: [odb-users] How to separate code in several dynamic libraries In-Reply-To: References: <1237832531.7825116.1527092174484.ref@mail.yahoo.com> <1237832531.7825116.1527092174484@mail.yahoo.com> Message-ID: <159547993.10291432.1527500733968@mail.yahoo.com> Hi Boris, Thank you for your answer. To answer your question I used the following options on odb : -d ; --at-once; --default-pointer and --std However I may have solved my problem this morning in the folowing way:- creating two libs with C++ classes and odb annotation called libModelA and libModelB (libModelA has dependency on some classes of libModelB). In those libraries no code has been generated by odb. - creating a library libOdbB which contains the generated code by odb and some other stuff (the odb software is applied on the annotated C++ files of libModelB) - creating a library libOdbA which contains the generated code by odb for the libModelA and only the required dependancies (i.e. a subset of libModelB). By doing this I have some code duplication in the generated files by odb (on the subset of classes of libModelB used by libModelA) but as it is automatically generated code, it is fine with me... Le jeudi 24 mai 2018 ? 18:27:54 UTC+2, Boris Kolpackov a ?crit : francois cellier writes: > Do you have any idea of how it should be done ? Show how (i.e., the ODB compiler command line) you generate the *-odb.* files for each library. From feiyunw at yahoo.com Thu May 31 11:04:21 2018 From: feiyunw at yahoo.com (Feiyun Wang) Date: Fri Jun 1 11:27:05 2018 Subject: [odb-users] libodb-mysql: no rule to update odb\mysql\details\(c|i|h)xx{options} References: <1719168489.679757.1527779061526.ref@mail.yahoo.com> Message-ID: <1719168489.679757.1527779061526@mail.yahoo.com> Hi, I got some error when building libodb-mysql with build2 and VS2017: ```` D:\Program Files (x86)\Microsoft Visual Studio\2017\Community>set PATH=C:\build2\bin;%PATH% D:\Program Files (x86)\Microsoft Visual Studio\2017\Community>cd /d d:\prj\odb\ d:\prj\odb>mkdir libodb-vs2017-release d:\prj\odb>b config.cxx=cl config.cc.coptions=/O2 "configure(libodb/@libodb-vs2017-release/)" ... d:\prj\odb>b libodb-vs2017-release/ ... d:\prj\odb>mkdir libmysqlclient-vs2017-release d:\prj\odb>b config.cxx=cl config.cc.coptions="/O2 /wd4819" "configure(libmysqlclient/@libmysqlclient-vs2017-release/)" ... d:\prj\odb>b libmysqlclient-vs2017-release/ ... d:\prj\odb>mkdir libodb-mysql-vs2017-release d:\prj\odb>b config.cxx=cl config.cc.coptions=/O2 config.import.libmysqlclient=libmysqlclient-vs2017-release/ config.import.libodb=libodb-vs2017-release/ "configure(libodb-mysql/@libodb-mysql-vs2017-release/)" mkdir -p libodb-mysql-vs2017-release\build\ save libodb-mysql-vs2017-release\build\config.build mkdir -p libodb-mysql-vs2017-release\tests\build\ save libodb-mysql-vs2017-release\tests\build\config.build d:\prj\odb>b libodb-mysql-vs2017-release/ error: no rule to update libodb-mysql-vs2017-release\odb\mysql\details\cxx{options} ??info: re-run with --verbose 4 for more information ??info: while applying rule cxx.compile to update libodb-mysql-vs2017-release\odb\mysql\details\obja{options} ??info: while applying rule cxx.link to update libodb-mysql-vs2017-release\odb\mysql\liba{odb-mysql} ??info: while applying rule bin.lib to update libodb-mysql-vs2017-release\odb\mysql\lib{odb-mysql} ??info: while applying rule alias to update libodb-mysql-vs2017-release\odb\dir{mysql\} ??info: while applying rule alias to update libodb-mysql-vs2017-release\dir{odb\} ??info: while applying rule alias to update dir{libodb-mysql-vs2017-release\} mkdir libodb-mysql-vs2017-release\fsdir{odb\} mkdir libodb-mysql-vs2017-release\odb\fsdir{mysql\} error: no rule to update libodb-mysql-vs2017-release\odb\mysql\details\ixx{options} ??info: re-run with --verbose 4 for more information ??info: while applying rule cxx.link to update libodb-mysql-vs2017-release\odb\mysql\liba{odb-mysql} ??info: while applying rule bin.lib to update libodb-mysql-vs2017-release\odb\mysql\lib{odb-mysql} ??info: while applying rule alias to update libodb-mysql-vs2017-release\odb\dir{mysql\} ??info: while applying rule alias to update libodb-mysql-vs2017-release\dir{odb\} ??info: while applying rule alias to update dir{libodb-mysql-vs2017-release\} error: no rule to update libodb-mysql-vs2017-release\odb\mysql\details\hxx{options} ??info: re-run with --verbose 4 for more information ??info: while applying rule cxx.link to update libodb-mysql-vs2017-release\odb\mysql\liba{odb-mysql} ??info: while applying rule bin.lib to update libodb-mysql-vs2017-release\odb\mysql\lib{odb-mysql} ??info: while applying rule alias to update libodb-mysql-vs2017-release\odb\dir{mysql\} ??info: while applying rule alias to update libodb-mysql-vs2017-release\dir{odb\} ??info: while applying rule alias to update dir{libodb-mysql-vs2017-release\} ver libodb-mysql\odb\mysql\version-build2.hxx.in info: failed to update dir{libodb-mysql-vs2017-release\} d:\prj\odb>b --verbose 4 libodb-mysql-vs2017-release/ ... cl -ID:\prj\odb\libodb-vs2017-release -ID:\prj\odb\libodb -DLIBODB_BUILD2 -DLIBODB_SHARED -ID:\prj\odb\libmysqlclient-vs2017-release -ID:\prj\odb\libmysqlclient -ID:\prj\odb\libodb-mysql-vs2017-release -ID:\prj\odb\libodb-mysql -DLIBODB_MYSQL_BUILD2 -DLIBODB_MYSQL_SHARED_BUILD /O2 /nologo /EHsc /MD /P /showIncludes /C /WX /Fi: D:\prj\odb\libodb-mysql-vs2017-release\odb\mysql\traits.dll.obj.ii /TP D:\prj\odb\libodb-mysql\odb\mysql\traits.cxx trace: cxx::compile_rule::extract_headers: non-existent header 'odb/mysql/details/options.hxx' trace: cxx::compile_rule::append_prefixes: overriding dependency prefix odb\ ??existing mapping to D:\prj\odb\libodb-mysql-vs2017-release\ priority 1 ??new mapping to??????D:\prj\odb\libodb-vs2017-release\ priority 0 trace: cxx::compile_rule::extract_headers: mapped as auto-generated D:\prj\odb\libodb-mysql-vs2017-release\odb\mysql\details\options.hxx trace: version::in_rule::match: no manifest prerequisite for target D:\prj\odb\libodb-mysql-vs2017-release\odb\mysql\details\hxx{options.hxx} trace: version::in_rule::match: no in file prerequisite for target D:\prj\odb\libodb-mysql-vs2017-release\odb\mysql\details\hxx{options.hxx} trace: file_rule::match: no existing file for target D:\prj\odb\libodb-mysql-vs2017-release\odb\mysql\details\hxx{options.hxx} error: no rule to update D:\prj\odb\libodb-mysql-vs2017-release\odb\mysql\details\hxx{options.hxx} ??info: while extracting header dependencies from D:\prj\odb\libodb-mysql\odb\mysql\cxx{database.cxx}@D:\prj\odb\libodb-mysql-vs2017-release\odb\mysql\ ??info: while applying rule cxx.compile to update D:\prj\odb\libodb-mysql-vs2017-release\odb\mysql\objs{database.dll.obj} ??info: while applying rule cxx.link to update D:\prj\odb\libodb-mysql-vs2017-release\odb\mysql\libs{odb-mysql.dll} ??info: while applying rule bin.lib to update D:\prj\odb\libodb-mysql-vs2017-release\odb\mysql\lib{odb-mysql} ??info: while applying rule alias to update D:\prj\odb\libodb-mysql-vs2017-release\odb\dir{mysql\} ??info: while applying rule alias to update D:\prj\odb\libodb-mysql-vs2017-release\dir{odb\} ??info: while applying rule alias to update D:\prj\odb\dir{libodb-mysql-vs2017-release\} trace: version::in_rule::match: no manifest prerequisite for target D:\prj\odb\libodb-mysql\odb\mysql\details\build2\h{config.h}@D:\prj\odb\libodb-mysql-vs2017-release\odb\mysql\details\build2\ trace: version::in_rule::match: no in file prerequisite for target D:\prj\odb\libodb-mysql\odb\mysql\details\build2\h{config.h}@D:\prj\odb\libodb-mysql-vs2017-release\odb\mysql\details\build2\ cl -ID:\prj\odb\libodb-vs2017-release -ID:\prj\odb\libodb -DLIBODB_BUILD2 -DLIBODB_STATIC -ID:\prj\odb\libmysqlclient-vs2017-release -ID:\prj\odb\libmysqlclient -ID:\prj\odb\libodb-mysql-vs2017-release -ID:\prj\odb\libodb-mysql -DLIBODB_MYSQL_BUILD2 -DLIBODB_MYSQL_STATIC_BUILD /O2 /nologo /EHsc /MD /P /showIncludes /C /WX /Fi: D:\prj\odb\libodb-mysql-vs2017-release\odb\mysql\traits.lib.obj.ii /TP D:\prj\odb\libodb-mysql\odb\mysql\traits.cxx trace: version::in_rule::match: no manifest prerequisite for target D:\prj\odb\libodb-mysql\odb\mysql\details\build2\h{config-vc.h}@D:\prj\odb\libodb-mysql-vs2017-release\odb\mysql\details\build2\ cl -ID:\prj\odb\libodb-vs2017-release -ID:\prj\odb\libodb -DLIBODB_BUILD2 -DLIBODB_STATIC -ID:\prj\odb\libmysqlclient-vs2017-release -ID:\prj\odb\libmysqlclient -ID:\prj\odb\libodb-mysql-vs2017-release -ID:\prj\odb\libodb-mysql -DLIBODB_MYSQL_BUILD2 -DLIBODB_MYSQL_STATIC_BUILD /O2 /nologo /EHsc /MD /P /showIncludes /C /WX /Fi: D:\prj\odb\libodb-mysql-vs2017-release\odb\mysql\transaction-impl.lib.obj.ii /TP D:\prj\odb\libodb-mysql\odb\mysql\transaction-impl.cxx trace: version::in_rule::match: no in file prerequisite for target D:\prj\odb\libodb-mysql\odb\mysql\details\build2\h{config-vc.h}@D:\prj\odb\libodb-mysql-vs2017-release\odb\mysql\details\build2\ trace: version::in_rule::match: no manifest prerequisite for target D:\prj\odb\libodb-mysql\odb\mysql\cxx{transaction.cxx}@D:\prj\odb\libodb-mysql-vs2017-release\odb\mysql\ trace: version::in_rule::match: no manifest prerequisite for target D:\prj\odb\libodb-mysql\odb\mysql\details\build2\h{config-vc-stub.h}@D:\prj\odb\libodb-mysql-vs2017-release\odb\mysql\details\build2\ trace: version::in_rule::match: no in file prerequisite for target D:\prj\odb\libodb-mysql\odb\mysql\cxx{transaction.cxx}@D:\prj\odb\libodb-mysql-vs2017-release\odb\mysql\ trace: version::in_rule::match: no in file prerequisite for target D:\prj\odb\libodb-mysql\odb\mysql\details\build2\h{config-vc-stub.h}@D:\prj\odb\libodb-mysql-vs2017-release\odb\mysql\details\build2\ trace: version::in_rule::match: no manifest prerequisite for target D:\prj\odb\libodb-mysql\odb\mysql\details\hxx{config.hxx}@D:\prj\odb\libodb-mysql-vs2017-release\odb\mysql\details\ cl -ID:\prj\odb\libodb-vs2017-release -ID:\prj\odb\libodb -DLIBODB_BUILD2 -DLIBODB_STATIC -ID:\prj\odb\libmysqlclient-vs2017-release -ID:\prj\odb\libmysqlclient -ID:\prj\odb\libodb-mysql-vs2017-release -ID:\prj\odb\libodb-mysql -DLIBODB_MYSQL_BUILD2 -DLIBODB_MYSQL_STATIC_BUILD /O2 /nologo /EHsc /MD /P /showIncludes /C /WX /Fi: D:\prj\odb\libodb-mysql-vs2017-release\odb\mysql\transaction.lib.obj.ii /TP D:\prj\odb\libodb-mysql\odb\mysql\transaction.cxx trace: version::in_rule::match: no manifest prerequisite for target D:\prj\odb\libodb-mysql\odb\mysql\details\build2\h{config-stub.h}@D:\prj\odb\libodb-mysql-vs2017-release\odb\mysql\details\build2\ trace: version::in_rule::match: no in file prerequisite for target D:\prj\odb\libodb-mysql\odb\mysql\details\hxx{config.hxx}@D:\prj\odb\libodb-mysql-vs2017-release\odb\mysql\details\ trace: version::in_rule::match: no in file prerequisite for target D:\prj\odb\libodb-mysql\odb\mysql\details\build2\h{config-stub.h}@D:\prj\odb\libodb-mysql-vs2017-release\odb\mysql\details\build2\ trace: version::in_rule::match: no manifest prerequisite for target D:\prj\odb\libodb-mysql\odb\mysql\details\hxx{conversion.hxx}@D:\prj\odb\libodb-mysql-vs2017-release\odb\mysql\details\ trace: search_existing_file: no existing file for prerequisite D:\prj\odb\libodb-mysql-vs2017-release\odb\mysql\:details\cxx{options.?} trace: version::in_rule::match: no manifest prerequisite for target D:\prj\odb\libodb-mysql\odb\mysql\details\hxx{export.hxx}@D:\prj\odb\libodb-mysql-vs2017-release\odb\mysql\details\ trace: version::in_rule::match: no in file prerequisite for target D:\prj\odb\libodb-mysql\odb\mysql\details\hxx{conversion.hxx}@D:\prj\odb\libodb-mysql-vs2017-release\odb\mysql\details\ trace: version::in_rule::match: no manifest prerequisite for target D:\prj\odb\libodb-mysql-vs2017-release\odb\mysql\details\cxx{options.?} trace: version::in_rule::match: no in file prerequisite for target D:\prj\odb\libodb-mysql\odb\mysql\details\hxx{export.hxx}@D:\prj\odb\libodb-mysql-vs2017-release\odb\mysql\details\ trace: version::in_rule::match: no manifest prerequisite for target D:\prj\odb\libodb-mysql-vs2017-release\odb\mysql\details\ixx{options.?} trace: version::in_rule::match: no in file prerequisite for target D:\prj\odb\libodb-mysql-vs2017-release\odb\mysql\details\cxx{options.?} trace: version::in_rule::match: no in file prerequisite for target D:\prj\odb\libodb-mysql-vs2017-release\odb\mysql\details\ixx{options.?} trace: file_rule::match: no existing file for target D:\prj\odb\libodb-mysql-vs2017-release\odb\mysql\details\cxx{options.cxx} trace: file_rule::match: no existing file for target D:\prj\odb\libodb-mysql-vs2017-release\odb\mysql\details\ixx{options.ixx} error: no rule to update D:\prj\odb\libodb-mysql-vs2017-release\odb\mysql\details\cxx{options.cxx} ??info: while applying rule cxx.compile to update D:\prj\odb\libodb-mysql-vs2017-release\odb\mysql\details\obja{options.lib.obj} ??info: while applying rule cxx.link to update D:\prj\odb\libodb-mysql-vs2017-release\odb\mysql\liba{odb-mysql.lib} ??info: while applying rule bin.lib to update D:\prj\odb\libodb-mysql-vs2017-release\odb\mysql\lib{odb-mysql} ??info: while applying rule alias to update D:\prj\odb\libodb-mysql-vs2017-release\odb\dir{mysql\} ??info: while applying rule alias to update D:\prj\odb\libodb-mysql-vs2017-release\dir{odb\} ??info: while applying rule alias to update D:\prj\odb\dir{libodb-mysql-vs2017-release\} error: no rule to update D:\prj\odb\libodb-mysql-vs2017-release\odb\mysql\details\ixx{options.ixx} ??info: while applying rule cxx.link to update D:\prj\odb\libodb-mysql-vs2017-release\odb\mysql\liba{odb-mysql.lib} ??info: while applying rule bin.lib to update D:\prj\odb\libodb-mysql-vs2017-release\odb\mysql\lib{odb-mysql} ??info: while applying rule alias to update D:\prj\odb\libodb-mysql-vs2017-release\odb\dir{mysql\} ??info: while applying rule alias to update D:\prj\odb\libodb-mysql-vs2017-release\dir{odb\} ??info: while applying rule alias to update D:\prj\odb\dir{libodb-mysql-vs2017-release\} cl -ID:\prj\odb\libodb-vs2017-release -ID:\prj\odb\libodb -DLIBODB_BUILD2 -DLIBODB_SHARED -ID:\prj\odb\libmysqlclient-vs2017-release -ID:\prj\odb\libmysqlclient -ID:\prj\odb\libodb-mysql-vs2017-release -ID:\prj\odb\libodb-mysql -DLIBODB_MYSQL_BUILD2 -DLIBODB_MYSQL_SHARED_BUILD /O2 /nologo /EHsc /MD /P /showIncludes /C /WX /Fi: D:\prj\odb\libodb-mysql-vs2017-release\odb\mysql\transaction.dll.obj.ii /TP D:\prj\odb\libodb-mysql\odb\mysql\transaction.cxx trace: cxx::compile_rule::extract_headers: non-existent header 'odb/mysql/details/options.hxx' trace: cxx::compile_rule::append_prefixes: overriding dependency prefix odb\ ??existing mapping to D:\prj\odb\libodb-mysql-vs2017-release\ priority 1 ??new mapping to??????D:\prj\odb\libodb-vs2017-release\ priority 0 trace: cxx::compile_rule::extract_headers: mapped as auto-generated D:\prj\odb\libodb-mysql-vs2017-release\odb\mysql\details\options.hxx info: failed to update D:\prj\odb\dir{libodb-mysql-vs2017-release\} d:\prj\odb> ```` My test versions are: - libodb-mysql Revision: dcd4b078c8da2ab68cb8fdadac52cae4499dd502 Author: Boris Kolpackov Date: 2018/5/29 21:18:38 Message: Adjust external dependencies to use ^-constraint - libodb Revision: 0930b3a28774175e3a984b6d77e3f7587f2844af Author: Boris Kolpackov Date: 2018/5/29 20:46:09 Message: Bump version to 2.5.0-b.7 - libmysqlclient Revision: a3852af60947ee6073818b70783f0b82b4813001 Author: Boris Kolpackov Date: 2018/5/31 15:10:07 Message: Bump version to 5.7.20+1, master is open for business Sincerely, Feiyun Wang