On 8/3/15 11:58 AM, Edward Diener wrote:
I don't know how "to run the whole serialization test suite" but here is what I have done:
It's just running all the tests via the normal boost build/bjam system. I'm in the habit of mentioning this because it's quite common for someone to post a "fix" that is "too trivial" to require testing and it's helpful for me to avoid this.
1) I have created PR "Changes to fix serialization for gcc and clang on Windows #19". This fixes the building of the serialization library for mingw(-64)/gcc, both regular and wide character.
I will consider this shortly. I've been trying to catch up on other stuff so I've got a few things pending with the serialization library maintenance. I'll look at the PR soon.
2) For clang I have been told that the system of exporting/importing individual member functions as opposed to entire class does not work, since clang will not export a class's RTTI unless the entire class is exported.
Hmmm - my problems showed up only when I enabled limited visibility. I managed to get all tests passing on gcc, clang, and msvc (with a little help from my friends). Then I got nailed by mingw which I couldn't figure out the visibility system. So while the build of the regular serialization library
succeeds it is probably not usable from other clang code.
hmmm - all the tests passed on my system with both static and shared library builds. This can be
seen in the fact that using your current system of exporting/importing individual member functions of a visible class I can not build the wide character serialization library using clang because it refuses to link with the dependent regular character serialization library.
Again, I'm not seeing this - I've only had problems with mingw So unless
you want to change the way that export/import works for clang on Windows clang on Windows will not work with serialization.
I can't remember right now whether I originally had been exporting the whole class or just function by function. It's been 6 months. One reason that it's more complicated with the serialization library is that there are two DLLS the core one and the wide character add-in. The second exports functions of it's own while importing functions from the core. This is doable, but confusing.
3) I have tested my changes with gcc and clang on Linux and with gcc, VC++, and clang on Windows. As explained above everything succeeds except clang on Windows, which also failed before my changes.
Hmmm - I'm not sure how this is different than the current status. As I said, my pending issues were with mingw. Since mingw is also a relative of windows - it wouldn't surprise me of clang for windows also has issues. I am interested in getting this sorted out since I want to keep the serialization library as widely applicable as possible and I appreciate your help with this (and other people too). On the other hand, I'm beginning to wonder. The problem with mingw has been there since 1.58 and no one has complained. Same goes for clang on windows. It's hard to get motivated to spend time making things work for platforms which it doesn't seem anyone is using.
If you could look at this PR and try it with your "whole serialization test suite" it would be appreciated.
I absolutely will, and soon. As I said, the whole test suite is just the normal boost build test. One thing that I do is run all the combinations of shared/static/debug/release for gcc and clang - I don't have a windows development system any more. This takes a while sucks up an incredible amount of disk space.
If you are willing to give the go ahead I can try changing clang on Windows so that the entire class is exported rather than individual member functions for that one-off case. It is pretty easy to test for clang on Windows using gcc at the preprocessor level. I do realize exporting the entire class in the one-off clang case changes your work in carefully honing visibility, for this single case, but I cannot change the way clang on Windows works. Changing for clang on Windows will not change any other compiler implementation but will make your code slightly messier.
LOL - you mean the serialization library is messy?
PS. I also created PR "Delete recreated files. #18" which deletes some files from Git which were being regenerated by serialization tests each time.
Fine. Again I much appreciate your efforts. I just need to find the time to give them attention they deserve. Robert Ramey