QxORM Build fails with under MinGW with Serialization

[SteveW]

Hi

Been on this one a couple of days to work out the various scenarios, now any help greatly appreciated...

First "Serialization" is enabled (we will later be using the QxService model for our project), so I have build the required boost libs fine with the Boostrap/b2 command line tools.

I'm using Qt Creator to build (with both MinGW and MCVS2013 compilers configured). With latest Boost (1.60.0), I can build the QxORM.lib using the MSVC compiler, but with MinGW if failes. First compiler error is:-

Code: Select all

...qxorm\source\include\QxSerialize\boost\QxSerialize_unordered_map.h:63: error: 'load_collection' is not a member of 'boost::serialization::stl'
    boost::serialization::stl::load_collection< Archive, boost::unordered_map<Key, Value>,


I need to have it building via MinGW building, as some of our developers don't have MSVC and so are relying on MinGW.

From my understanding, MinGW is attempting to "compile" that code even though it's a template function, whereas MSVC doesn't process it until the template is used. So I think I get why it's not building with MinGW, but MSVC is ok.

And from reading further into it, the "load_collection" method is/was an internal part of the Boost lib API, and external libraries (ie QxORM), should not be using it, and indeed that method looks like it has been removed.

I reverted boost back to 1.56.0 and I can build the all the QxORM.LIBs (MSVC, MinGW etc etc).

However, first, when I move to the next stage (building the QxORM test/tutorial project), I start getting copmiler errors in the Boost headers about missing .hpp files (my include paths are ok, the .HPP files are physically not present, I have checked!).

Second, I don't want our code base to be fixed on an older version of Boost, so I have re-reverted the Boost libs back to V1.60.0

With MSVC I can build/run/debug the QxBlog tutorials fine. And I'd hoped that I could build the QxBlog tutorial with MinGW only linking in the pre-built MSVC QxORM lib, but sadly not... The QxBlog compilation fails with exactly the same compiler error...

Code: Select all

...qxorm\source\include\QxSerialize\boost\QxSerialize_unordered_map.h:63: error: 'load_collection' is not a member of 'boost::serialization::stl'
    boost::serialization::stl::load_collection< Archive, boost::unordered_map<Key, Value>,


So is QxORM/MinGW not compatible with boost 1.60.0. I am doubtful that's the case and am more suspicious that I have just not got something right.

Thanks
Steve.

[qxorm]

Hello,

* "Serialization" is enabled (we will later be using the QxService model for our project).

boost is not required to use QxService module.
You can use QDataStream engine (qx::service::QxConnect::serialization_qt) or in the future version JSON engine (qx::service::QxConnect::serialization_json) to transfer your data over network.
Each serialization types has advantages/disadvantages, please read the manual here for more details : http://www.qxorm.com/qxorm_en/manual.html#manual_60

* From my understanding, MinGW is attempting to "compile" that code even though it's a template function, whereas MSVC doesn't process it until the template is used.

Yes, MSVC and MinGW manages template instantiation in a different way.
And it could explain too why MSVC is faster to compile than MinGW.

* I don't want our code base to be fixed on an older version of Boost ... is QxORM/MinGW not compatible with boost 1.60.0.

QxOrm must support latest version of Qt and boost.
So if there is a problem with boost 1.60, it must be fixed.

* error: 'load_collection' is not a member of 'boost::serialization::stl'

I will change the serialization process of boost::unordered_map, boost::unordered_set, std::unordered_map and std::unordered_set using public API when boost > 1.57.
I will provide you a BETA version of QxOrm 1.4.2 when it will be ready...

[SteveW]

Hi,

Thanks for the fast and helpful reply.

Do you have an ETA for this beta you mention? If it's going to be in the range of a few days, or 2-3 weeks then I can hold out before deploying the project to our MinGW only developers. If it's into the months range, I'll have to consider alternatives, disabling Serialization may be an option (possibly the only option).

Without understanding the full consequences at this stage (as I am fairly new to Boost and very new to QxORM/QxEE), the comment section of the .pri regarding serialization that caught my attention was:

Code: Select all

# Without this compilation option...
# ...serialization features are limited (based on QDataStream Qt engine) : limited qx::clone, no qx::dump, no XML serialization, limited binary serialization, limited QxService module (network transactions), etc...


As well as being concerned about the "limited" QsService support (not sure what those limits are yet!), I don't know the full possibilties of "QxDump" but it sounds useful, as does XML serialization, so don't want to have them unavailable for research etc. And finally as our database will almost certainly be holding some binary data, I did not want to hit unexpected limitations with this data that could have been easily avoided by using Boost serialization.

With all those consideration taken into account, it seemed prudent to have serialization enabled from the beginning of the project instead of finding these limitations (and problems such as this) when development ramps.

Thanks again,
Steve.

[qxorm]

Do you have an ETA for this beta you mention?

Here is a link to download the current BETA version of QxOrm 1.4.2 : http://www.qxorm.com/version/QxOrm_1.4.2_BETA_26.zip
I changed boost::unordered_map and boost::unordered_set serialization functions when boost version > 1.57.
To be honest, I have not tested this modification (I don't have boost 1.60 installed yet), but it should be ok now.

The main feature of QxOrm 1.4.2 is JSON serialization support.
It is not finished yet on current BETA version, so if you have any problem with JSON, please define _QX_NO_JSON compilation option (new compilation option available at the end of QxOrm.pri file).

Please let me know if you have any problem with this BETA version.

[SteveW]

Hi.

Many thanks for this Beta version, and for it so soon. I have been impressed by the speed of replies and helpfulness on this issue.

This cures the original compilation errors with MinGW I reported and (with some .PRO/.PRI changes to handle different library paths etc) I can now build the QxBlog tutorial program with both MSVC2013 and MinGW in QtCreator from the same .PRO file (I have both "Kits" setup with QtCreator).

Steve.

[qxorm]

This cures the original compilation errors with MinGW I reported ... I can now build the QxBlog tutorial program with both MSVC2013 and MinGW

Great !

with some .PRO/.PRI changes to handle different library paths etc

You should use environment variables to switch between MSVC/MinGW without having to change QxOrm.pri file.
You can take a look at the ./tools/ directory of QxOrm package (files mingw*.bat and msvc*.bat) : I can build using MSVC (several versions), or MinGW (several versions too) for Qt4, Qt5, several versions of boost, etc... without changing the QxOrm.pri file.