From luca.paganotti at gmail.com Sun May 2 13:42:19 2021 From: luca.paganotti at gmail.com (luca paganotti) Date: Sun May 2 13:42:42 2021 Subject: [odb-users] odb::query problem Message-ID: Hi all, after a week of trial I decided to take a real go with odb. I need to map a postgresql database with timescale extension. In order to map a time series table and then some continuous aggregates on my data I can't define a primary key so I defined a composite id on my data table. I'm using boost profiles smart-ptr, date-time and unordered. I've tried to use the complete boost profile but odb complains so I specify each single profile on the odb command line, more: I'm unable to use the details boost profile as odb compiler complains because it can't find a details.options file. I'm using debian buster which delivers a 2.4 release of odb. I checked in /usr/include/odb/boost/details and the details.options file it's not present meanwhile are present all the other options files. Missing something? I'll make a simpler example here in order to describe my problem without bothering with namespace and other unuseful details. I defined a class as my key, let's say #pragma db value class mykey with three public fields: s // std::string t // boost::posix_time::ptime i // an integer (that's really an enum) I defined a default constructor, a copy constructor a virtual destructor. I overloaded the assignment operator and the less than operator as described in the odb docs. I then defined a class let's say #pragma db object pointer(boost::shared_ptr) class myclass which has a mykey member with set and get methods and a circular relation with itself ... #pragma db id mykey key_; ... mykey& get_key() { return key_; } void set_key(mykey& k) { key_ = k; } ... #pragma db null boost::shared_ptr prev_; ... I'm able to persist myclass objects and timescale aggregates data as I want, and this is fine. Now I would like to query/erase some of them, so, following the docs I wrote something like that figuring out this code ... odb::transaction t (mydb->begin()); typedef odb::query myquery; mykey kf; mykey kt; kf.s = kt.s = strval; kf.i = kt.i = intval; kf.t = from; // start timestamp kt.t = to; // end timestamp mydb->erase_query(myquery::key_ >= kf && myquery::key_ <= kt); ... Running this instruction gives me an incomplete type error like incomplete type ?myquery? {aka ?odb::query?} used in nested name specifier All my persistent classes are inside the same include file, so I'm wondering why the c++ compiler gives me this error. Is it because of the prev_ myclass member? Can I solve this? Am I missing something else? Can someone help please or drive me to the right source of info or non trivial example? Thank you, have a nice week. ---------------------------------------------------------------- -- Dott. Ing. Luca Paganotti -- luca.paganotti@gmail.com -- https://github.com/lucapaganotti -- sourceforge email: -- lucapaganotti@users.sourceforge.net -- skype name: luca.paganotti [image: http://it.linkedin.com/in/lucapaganotti] -- --------------------------------------------------------------- -- Mistakes are portals of discovery - JAAJ --- -------------------------------------------------------------- From boris at codesynthesis.com Mon May 3 07:01:29 2021 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon May 3 07:01:09 2021 Subject: [odb-users] odb::query problem In-Reply-To: References: Message-ID: luca paganotti writes: > I've tried to use the complete boost profile but odb complains so I specify > each single profile on the odb command line, more: I'm unable to use the > details boost profile as odb compiler complains because it can't find a > details.options file. > I'm using debian buster which delivers a 2.4 release of odb. > I checked in /usr/include/odb/boost/details and the details.options file > it's not present meanwhile are present all the other options files. Missing > something? There is no such profile (the details/ subdirectory you are seeing in libodb-boost is the library's own implementation details). > typedef odb::query myquery; Why are you passing mykey as a second template argument to odb::query? Have you seen such an instruction anywhere in the documentation (because it's wrong and we would want to fix that)? From attilio.priolo at gmail.com Mon May 3 06:36:53 2021 From: attilio.priolo at gmail.com (Attilio Priolo) Date: Mon May 3 07:01:26 2021 Subject: [odb-users] PostgreSQL declarative partitioning - generated schema file Message-ID: Dear all, I am trying to exploit the PostgreSQL declarative partitioning feature into the application I am currently working on. I was able to use it by manually modifying the SQL schema creation file produced by ODB command line tool. However, I would like to instruct ODB to add this partitioning clause on my behalf (e.g. using a pragma). I looked through the manual several times but I haven't found a way to do it. Do you have any suggestions? Any help would be appreciated. Regards, AP From boris at codesynthesis.com Mon May 3 07:04:01 2021 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon May 3 07:03:41 2021 Subject: [odb-users] PostgreSQL declarative partitioning - generated schema file In-Reply-To: References: Message-ID: Attilio Priolo writes: > I was able to use it by manually modifying the SQL schema creation file > produced by ODB command line tool. > However, I would like to instruct ODB to add this partitioning clause on my > behalf (e.g. using a pragma). Can you show/describe what kind of changes you need in the generated schema? From attilio.priolo at gmail.com Mon May 3 08:21:22 2021 From: attilio.priolo at gmail.com (Attilio Priolo) Date: Mon May 3 09:54:56 2021 Subject: [odb-users] PostgreSQL declarative partitioning - generated schema file In-Reply-To: References: Message-ID: Hello Boris, Thank you for your prompt reply. Let me show you an example: - Original generated schema file ... CREATE TABLE "event_log" ( "id_timestamp" TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, "id_id" BIGSERIAL NOT NULL, "typeid" TEXT NOT NULL, "timestamp" TIMESTAMP NULL DEFAULT CURRENT_TIMESTAMP, "ept" BIGINT NULL, PRIMARY KEY ("id_timestamp", "id_id"), CONSTRAINT "ept_fk" FOREIGN KEY ("ept") REFERENCES "ept" ("id") INITIALLY DEFERRED); ... The modified version to be used as declarative partitioning parent table is the following: CREATE TABLE "event_log" ( "id_timestamp" TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, "id_id" BIGSERIAL NOT NULL, "typeid" TEXT NOT NULL, "timestamp" TIMESTAMP NULL DEFAULT CURRENT_TIMESTAMP, "ept" BIGINT NULL, PRIMARY KEY ("id_timestamp", "id_id"), CONSTRAINT "ept_fk" FOREIGN KEY ("ept") REFERENCES "ept" ("id") INITIALLY DEFERRED) PARTITION BY RANGE("timestamp"); To summarize, I would like to add the "PARTITION BY" during the schema generation step because PostgreSQL does not support altering an existing table into a partitioned one. Any suggestions? Best, Attilio Il giorno lun 3 mag 2021 alle ore 13:04 Boris Kolpackov < boris@codesynthesis.com> ha scritto: > Attilio Priolo writes: > > > I was able to use it by manually modifying the SQL schema creation file > > produced by ODB command line tool. > > However, I would like to instruct ODB to add this partitioning clause on > my > > behalf (e.g. using a pragma). > > Can you show/describe what kind of changes you need in the generated > schema? > From luca.paganotti at gmail.com Mon May 3 12:17:20 2021 From: luca.paganotti at gmail.com (luca paganotti) Date: Mon May 3 12:17:44 2021 Subject: [odb-users] odb::query problem In-Reply-To: References: Message-ID: Hi, thanks for your reply. Ok for the details directory, however I need to specify each single profile on odb command line and I get this error "odb: error: unable to locate options file for profile 'boost'" when I specify -p boost only, but I think it's a minor problem, better not a problem at all. As to my source code, I'm afraid I trusted too much the bug icon in eclipse, it was steady there and went away when I added the second template parameter so I went on ..., you're right it's not in the docs, my mistake ... As off today I think the indexer has done its job and the bug icon it's not on that line anymore, sorry for the noise, my fault. Now the code is odb::transaction t (mydb->begin()); typedef odb::query myquery; mykey kf; mykey kt; kf.s = kt.s = strval; kf.i = kt.i = intval; kf.t = from; // start timestamp kt.t = to; // end timestamp mydb->erase_query(myquery::key_ >= kf && myquery::key_ <= kt); anyway g++ complains this way on the last statement: error: ?key_? is not a member of ?myquery? {aka ?odb::query?} I overloaded >, >=, <= operators like this one bool operator < (const mykey& k) const { ... } So it seems, key_ it's not a member of myquery that instead has a key member, using that g++ gives tons of errors mainly saying that operands for the overloaded operators are not of the same type the first operand is of type const odb::query_columns >::key_class_ and the second one is of type mykey. As an additional info, I'm able to use the query functions that get a std::string as parameter, but it will be nice to be able to use also the others. Have a nice day ---------------------------------------------------------------- -- Dott. Ing. Luca Paganotti -- luca.paganotti@gmail.com -- https://github.com/lucapaganotti -- sourceforge email: -- lucapaganotti@users.sourceforge.net -- skype name: luca.paganotti [image: http://it.linkedin.com/in/lucapaganotti] -- --------------------------------------------------------------- -- Mistakes are portals of discovery - JAAJ --- -------------------------------------------------------------- On Mon, May 3, 2021 at 1:01 PM Boris Kolpackov wrote: > luca paganotti writes: > > > I've tried to use the complete boost profile but odb complains so I > specify > > each single profile on the odb command line, more: I'm unable to use the > > details boost profile as odb compiler complains because it can't find a > > details.options file. > > I'm using debian buster which delivers a 2.4 release of odb. > > I checked in /usr/include/odb/boost/details and the details.options file > > it's not present meanwhile are present all the other options files. > Missing > > something? > > There is no such profile (the details/ subdirectory you are seeing in > libodb-boost is the library's own implementation details). > > > > typedef odb::query myquery; > > Why are you passing mykey as a second template argument to odb::query? > Have you seen such an instruction anywhere in the documentation (because > it's wrong and we would want to fix that)? > From boris at codesynthesis.com Tue May 4 09:25:25 2021 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue May 4 09:25:12 2021 Subject: [odb-users] odb::query problem In-Reply-To: References: Message-ID: luca paganotti writes: > mydb->erase_query(myquery::key_ >= kf && myquery::key_ <= kt); > > anyway g++ complains this way on the last statement: > > error: ?key_? is not a member of ?myquery? {aka ?odb::query?} Right, but query::key is, as described in the documentation (ODB removes data member decorations like `m_` and trailing `_` for query members). > So it seems, key_ it's not a member of myquery that instead has a key > member, using that g++ gives tons of errors mainly saying that operands for > the overloaded operators are not of the same type > the first operand is of type > > const odb::query_columns odb::access::object_traits_impl >::key_class_ > > and the second one is of type mykey. > > As an additional info, I'm able to use the query functions that get a > std::string as parameter, but it will be nice to be able to use also the > others. Key is a composite value (it contains multiple members) so you need to pick the member you want to compare to, as in, query::key.member. From attilio.priolo at gmail.com Tue May 4 03:11:36 2021 From: attilio.priolo at gmail.com (Attilio Priolo) Date: Tue May 4 09:25:27 2021 Subject: [odb-users] PostgreSQL declarative partitioning - generated schema file In-Reply-To: References: Message-ID: Just for the record, there is a typo in the modified version I sent. The partition key column is "id_timestamp" not "timestamp" (according to Limitations 5.11.2.3 section in https://www.postgresql.org/docs/12/ddl-partitioning.html section) Regards, AP From boris at codesynthesis.com Tue May 4 09:29:16 2021 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue May 4 09:28:54 2021 Subject: [odb-users] PostgreSQL declarative partitioning - generated schema file In-Reply-To: References: Message-ID: Attilio Priolo writes: > CREATE TABLE "event_log" ( > "id_timestamp" TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, > "id_id" BIGSERIAL NOT NULL, > "typeid" TEXT NOT NULL, > "timestamp" TIMESTAMP NULL DEFAULT CURRENT_TIMESTAMP, > "ept" BIGINT NULL, > PRIMARY KEY ("id_timestamp", > "id_id"), > CONSTRAINT "ept_fk" > FOREIGN KEY ("ept") > REFERENCES "ept" ("id") > INITIALLY DEFERRED) > PARTITION BY RANGE("timestamp"); > > To summarize, I would like to add the "PARTITION BY" during the schema > generation step because PostgreSQL does not support altering an existing > table into a partitioned one. > Any suggestions? Thanks for the example. There is currently no good way to achieve this. But we've had a similar request some time ago so perhaps it's time to add support for table options (similar to column options). I could try to implement this in the coming weeks if you would be willing to try it out. From attilio.priolo at gmail.com Tue May 4 09:39:15 2021 From: attilio.priolo at gmail.com (Attilio Priolo) Date: Tue May 4 09:50:59 2021 Subject: [odb-users] PostgreSQL declarative partitioning - generated schema file In-Reply-To: References: Message-ID: Thanks Boris. I would be pleased to try it out. AP From luca.paganotti at gmail.com Tue May 4 16:56:59 2021 From: luca.paganotti at gmail.com (luca paganotti) Date: Tue May 4 16:57:25 2021 Subject: [odb-users] odb::query problem In-Reply-To: References: Message-ID: Hi Boris, thanks, nice to know, what I was thinking about was that I could be able to directly compare mykey objects as I declared them overriding the < operator as the docs say operator < must be defined for composite values (and to tell the truth I overrided also >= , <=, > == and != operators for class mykey), I didn't imagine that I would split the comparing expression using all the mykey members to this detail. I wrote the query condition as myquery::key >= kf && myquery::key <= kt where kf and kt are myquery instances, instead of myquery::key.t >= from && myquery::key.t <= to && myquery::key.s == strval && myquery::key.i == intval but the latter is compiling and working. Thank you. ---------------------------------------------------------------- -- Dott. Ing. Luca Paganotti -- Via dei Giardini 9 -- 21035 Cunardo (VA) -- 393 1346898 ---------------------------------------------------------------- -- softech s.r.l. email: -- luca.paganotti@softechweb.it -- luca.paganotti@gmail.com -- https://github.com/lucapaganotti -- sourceforge email: -- lucapaganotti@users.sourceforge.net -- skype name: luca.paganotti [image: http://it.linkedin.com/in/lucapaganotti] -- --------------------------------------------------------------- -- Mistakes are portals of discovery - JAAJ --- -------------------------------------------------------------- On Tue, May 4, 2021 at 3:25 PM Boris Kolpackov wrote: > luca paganotti writes: > > > mydb->erase_query(myquery::key_ >= kf && myquery::key_ <= kt); > > > > anyway g++ complains this way on the last statement: > > > > error: ?key_? is not a member of ?myquery? {aka ?odb::query?} > > Right, but query::key is, as described in the documentation (ODB > removes data member decorations like `m_` and trailing `_` for > query members). > > > > So it seems, key_ it's not a member of myquery that instead has a key > > member, using that g++ gives tons of errors mainly saying that operands > for > > the overloaded operators are not of the same type > > the first operand is of type > > > > const odb::query_columns > odb::access::object_traits_impl > >::key_class_ > > > > and the second one is of type mykey. > > > > As an additional info, I'm able to use the query functions that get a > > std::string as parameter, but it will be nice to be able to use also the > > others. > > Key is a composite value (it contains multiple members) so you need > to pick the member you want to compare to, as in, query::key.member. > From boris at codesynthesis.com Wed May 5 07:38:54 2021 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed May 5 07:38:32 2021 Subject: [odb-users] odb::query problem In-Reply-To: References: Message-ID: luca paganotti writes: > nice to know, what I was thinking about was that I could be able to > directly compare mykey objects as I declared them overriding the < operator > as the docs say operator < must be defined for composite values (and to > tell the truth I overrided also >= , <=, > == and != operators for class > mykey), I didn't imagine that I would split the comparing expression using > all the mykey members to this detail. > > I wrote the query condition as > > myquery::key >= kf && myquery::key <= kt > > where kf and kt are myquery instances, instead of > > myquery::key.t >= from && > myquery::key.t <= to && > myquery::key.s == strval && > myquery::key.i == intval > > but the latter is compiling and working. The operators that you wrote are for comparisons that are executed in your application. In contrast, when you write something like (myquery::key.s == strval), it must be executed in the database. To achieve this, there are special overloads of these operators (supplied by the ODB runtime) that translate the comparisons to SQL. Since the key type is a custom type that the ODB runtime doesn't know anything about, it cannot possibly provide such overloads for it. But if you feel adventures (and your C++ meta-programming abilities are quite strong), you can try to implement them yourself. I think it should be possible (though I don't think I've tried). From emilio.garcia at ieec.cat Mon May 10 07:59:00 2021 From: emilio.garcia at ieec.cat (Emilio Garcia) Date: Mon May 10 07:58:49 2021 Subject: [odb-users] ODB Named pragmas Message-ID: Hi all, I am checking the ODB Manual and I saw in 14 ODB Pragma Language Chapter that is possible to make use of #include directive to include the file with the odb pragma. But, I wondered if it is possible to do the other way round, to avoid putting odb things in the source header file. Let's take the example shown in the manual: // person.hxx class person { ... }; #ifdef ODB_COMPILER # include "person-pragmas.hxx" #endif And I would like to have: // person.hxx class person { ... }; // person-pragmas.hxx #include "person.hxx" #pragma db object(person) #pragma db member(person::id_) id I must admit that I did not tried yet, I just wanted to confirm with you if it is possible and If it would have any side-effect before going into this approach. Thanks in advance, -- Emilio Garcia Quintana emilio.garcia@ice.csic.es *Software Engineer* Tel: +34 93 737 97 88 Ext: 933002 Campus UAB, Carrer de Can Magrans, s/n 08193 Cerdanyola del Vall?s ICE IEEC CSIC Logos Institute of Space Science (IEEC-CSIC) http://www.ice.csic.es From boris at codesynthesis.com Tue May 11 08:53:37 2021 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue May 11 08:53:15 2021 Subject: [odb-users] ODB Named pragmas In-Reply-To: References: Message-ID: Emilio Garcia writes: > And I would like to have: > > // person.hxx > class person > { > ... > }; > > // person-pragmas.hxx > > #include "person.hxx" > > #pragma db object(person) > #pragma db member(person::id_) id > > I must admit that I did not tried yet, I just wanted to confirm with you if > it is possible and If it would have any side-effect before going into this > approach. There are two ways you can achieve this. The first is described in the introduction of Chapter 14, "ODB Pragma Language"[1] and involves using the --odb-epilogue option to non-invasively include the person-pragmas.hxx header when compiling person.hxx with the ODB compiler. The alternative solution is to use the definition pragma[2] and compile person-pragmas.hxx. One side-effect of this approach is that the generated person-odb.hxx file will include person-pragmas.hxx and not person.hxx directly. [1] https://codesynthesis.com/products/odb/doc/manual.xhtml#14 [2] https://codesynthesis.com/products/odb/doc/manual.xhtml#14.3.7 From becoggins at hotmail.com Sat May 15 15:09:28 2021 From: becoggins at hotmail.com (Brian Coggins) Date: Sat May 15 15:09:14 2021 Subject: [odb-users] Getting the ODB Compiler to Find the System Headers After macOS Catalina Update Message-ID: Dear all, I recently updated a macOS system from Mojave to Catalina (yes, I know I'm behind a bit!) and I'm trying to figure out the right/best way to help the ODB compiler find the system headers. For those who are not familiar, Catalina abandons /usr/include; the system headers are now deep inside an XCode directory, which the Apple-provided clang knows how to find. But the odb compiler does not know how to find the new include directory. One option would be to modify every Makefile that calls odb, explicitly providing it with the new include path. But it seems like there must be a better way. Some compilers seem to be able to follow a SYSROOT environment variable to find Catalina headers, but my odb compiler build does not seem to recognize SYSROOT. Has anyone dealt with this in Catalina or Big Sur and found an elegant solution? (I built odb using build2 and Homebrew gcc-9. odb version is 2.5.0-b.17. Homebrew gcc is 9.2.0) Thanks, Brian From boris at codesynthesis.com Mon May 17 06:56:01 2021 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon May 17 06:55:33 2021 Subject: [odb-users] Getting the ODB Compiler to Find the System Headers After macOS Catalina Update In-Reply-To: References: Message-ID: Brian Coggins writes: > I recently updated a macOS system from Mojave to Catalina (yes, I know > I'm behind a bit!) and I'm trying to figure out the right/best way to > help the ODB compiler find the system headers. > > For those who are not familiar, Catalina abandons /usr/include; the > system headers are now deep inside an XCode directory, which the > Apple-provided clang knows how to find. But the odb compiler does > not know how to find the new include directory. > > (I built odb using build2 and Homebrew gcc-9. odb version is 2.5.0-b.17. > Homebrew gcc is 9.2.0) I would expect Homebrew GCC to be patched to deal with this (otherwise it would be unusable) with ODB piggybacking on it. Have you tried upgrading to a more recent version of GCC (e.g., 10) and rebuilding the ODB compiler to match? From becoggins at hotmail.com Mon May 17 11:45:21 2021 From: becoggins at hotmail.com (Brian Coggins) Date: Mon May 17 11:45:03 2021 Subject: [odb-users] Getting the ODB Compiler to Find the System Headers After macOS Catalina Update In-Reply-To: References: , Message-ID: I'm giving that a try, and with homebrew gcc updated to gcc 11, I'm getting errors in the ODB compilation. I updated build2 to 0.13.0, set up a new build configuration of odb-gcc-11, and build2 is trying to update ODB to 2.5.0-b.19+1 from the b.17 that I was on previously. After these lines: fetched odb/2.5.0-b.19+1 unpacked odb/2.5.0-b.19+1 configured odb/2.5.0-b.19+1 version.in libstudxml-1.1.0-b.9/libstudxml/version.hxx.in the following error prints 16 times in a row: /usr/local/Cellar/gcc/11.1.0/lib/gcc/11/gcc/x86_64-apple-darwin19/11.1.0/plugin/include/cp/name-lookup.h:498:24: error: module name expected instead of info: while scanning odb-2.5.0-b.19+1/odb/cxx{include} info: while applying rule cxx.compile to update odb-2.5.0-b.19+1/odb/objs{include} info: while applying rule cxx.link to update odb-2.5.0-b.19+1/odb/libus{odb} info: while applying rule cxx.link to update odb-2.5.0-b.19+1/odb/plugin{odb} info: while applying rule alias to update odb-2.5.0-b.19+1/dir{odb/} info: while applying rule alias to update dir{odb-2.5.0-b.19+1/} Any ideas? Brian ________________________________ From: Boris Kolpackov Sent: Monday, May 17, 2021 6:56 AM To: Brian Coggins Cc: odb-users@codesynthesis.com Subject: Re: [odb-users] Getting the ODB Compiler to Find the System Headers After macOS Catalina Update Brian Coggins writes: > I recently updated a macOS system from Mojave to Catalina (yes, I know > I'm behind a bit!) and I'm trying to figure out the right/best way to > help the ODB compiler find the system headers. > > For those who are not familiar, Catalina abandons /usr/include; the > system headers are now deep inside an XCode directory, which the > Apple-provided clang knows how to find. But the odb compiler does > not know how to find the new include directory. > > (I built odb using build2 and Homebrew gcc-9. odb version is 2.5.0-b.17. > Homebrew gcc is 9.2.0) I would expect Homebrew GCC to be patched to deal with this (otherwise it would be unusable) with ODB piggybacking on it. Have you tried upgrading to a more recent version of GCC (e.g., 10) and rebuilding the ODB compiler to match? From emilio.garcia at ice.csic.es Tue May 18 03:14:16 2021 From: emilio.garcia at ice.csic.es (Emilio Garcia) Date: Tue May 18 05:58:51 2021 Subject: [odb-users] ODB Named pragmas In-Reply-To: References: Message-ID: <8dbcc49f-696e-02c3-258a-8ea97800d6a2@ice.csic.es> Hi team, Many thanks for your support. I saw the definition pragma link, but I was guessing if it should work with both value types and object types since the example shows only the first one. Thanks again! Emilio Garcia Quintana emilio.garcia@ice.csic.es *Software Engineer* Tel: +34 93 737 97 88 Ext: 933002 Campus UAB, Carrer de Can Magrans, s/n 08193 Cerdanyola del Vall?s ICE Logo Institute of Space Sciences (CSIC-IEEC) http://www.ice.csic.es On 5/11/21 2:53 PM, Boris Kolpackov wrote: > Emilio Garcia writes: > >> And I would like to have: >> >> // person.hxx >> class person >> { >> ... >> }; >> >> // person-pragmas.hxx >> >> #include "person.hxx" >> >> #pragma db object(person) >> #pragma db member(person::id_) id >> >> I must admit that I did not tried yet, I just wanted to confirm with you if >> it is possible and If it would have any side-effect before going into this >> approach. > There are two ways you can achieve this. The first is described in > the introduction of Chapter 14, "ODB Pragma Language"[1] and > involves using the --odb-epilogue option to non-invasively include > the person-pragmas.hxx header when compiling person.hxx with the ODB > compiler. > > The alternative solution is to use the definition pragma[2] and > compile person-pragmas.hxx. One side-effect of this approach is > that the generated person-odb.hxx file will include person-pragmas.hxx > and not person.hxx directly. > > [1] https://codesynthesis.com/products/odb/doc/manual.xhtml#14 > [2] https://codesynthesis.com/products/odb/doc/manual.xhtml#14.3.7 > From boris at codesynthesis.com Tue May 18 06:16:11 2021 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue May 18 06:15:43 2021 Subject: [odb-users] Getting the ODB Compiler to Find the System Headers After macOS Catalina Update In-Reply-To: References: Message-ID: Brian Coggins writes: > I'm giving that a try, and with homebrew gcc updated to gcc 11, I'm > getting errors in the ODB compilation. I updated build2 to 0.13.0, > set up a new build configuration of odb-gcc-11, and build2 is trying > to update ODB to 2.5.0-b.19+1 from the b.17 that I was on previously. I would suggest that you try GCC 10 instead because (1) 11 was just released and I would not be surprised if there are still issues with the Homebrew port and (2) ODB 2.5.0-b.19 does not support GCC 11. If, however, you would like to stick with GCC 11, then you can try build2/ODB from the staging repository (the version of ODB there supports GCC 11): https://build2.org/community.xhtml#stage From becoggins at hotmail.com Tue May 18 23:55:48 2021 From: becoggins at hotmail.com (Brian Coggins) Date: Tue May 18 23:55:32 2021 Subject: [odb-users] Getting the ODB Compiler to Find the System Headers After macOS Catalina Update In-Reply-To: References: , Message-ID: That worked: gcc-10 solves the header issue in Catalina, while being compatible with ODB 2.5.0-b.19. Thanks! Brian ________________________________ From: Boris Kolpackov Sent: Tuesday, May 18, 2021 6:16 AM To: Brian Coggins Cc: odb-users@codesynthesis.com Subject: Re: [odb-users] Getting the ODB Compiler to Find the System Headers After macOS Catalina Update Brian Coggins writes: > I'm giving that a try, and with homebrew gcc updated to gcc 11, I'm > getting errors in the ODB compilation. I updated build2 to 0.13.0, > set up a new build configuration of odb-gcc-11, and build2 is trying > to update ODB to 2.5.0-b.19+1 from the b.17 that I was on previously. I would suggest that you try GCC 10 instead because (1) 11 was just released and I would not be surprised if there are still issues with the Homebrew port and (2) ODB 2.5.0-b.19 does not support GCC 11. If, however, you would like to stick with GCC 11, then you can try build2/ODB from the staging repository (the version of ODB there supports GCC 11): https://build2.org/community.xhtml#stage