THRIFT-4759:add thrift export to fix windows shared lib building

[cyyever]

add thrift export to fix windows shared lib building

[cyyever]

This PR is same with #1713.
Given that the support for GNU autotools is not dropped,I decided to add the cmake generated header to the source tree.And the header was changed a little to avoid errors in gcc/clang.
And I only added the macro to problematic locations.

[jeking3]

We're moving towards cmake but it's going to take a while to get everything that autoconf does for us working in cmake... in the meantime thanks for both. The "make dist" job in Travis CI failed and it looks related.

[jeking3]

Long term, we really should put THRIFT_EXPORT on all classes, and disable global visibility on unixy builds like boost does, that way unix and windows are playing the same export game.

[cyyever]

We're moving towards cmake but it's going to take a while to get everything that autoconf does for us working in cmake... in the meantime thanks for both. The "make dist" job in Travis CI failed and it looks related.

I forgot to change autotool scripts,I will re-push it.

[cyyever]

@jeking3 by the way,are there any plans to merge fbthrift code?

[cyyever]

Long term, we really should put THRIFT_EXPORT on all classes, and disable global visibility on unixy builds like boost does, that way unix and windows are playing the same export game.

That is a huge work,and I found little UNIX/Linux cpp projects limiting symbol visibility.It is a good idea except to make code a little ugly.

[jeking3]

Boost leads the way in terms of correctness here, just a suggestion for long term.

[jeking3]

I think I prefer the other PR for this issue. We don't use autoconf for any build that needs dllimport/export - we only use cmake. Therefore a cmake-centric solution is appropriate, especially if nobody wants to tackle symbol visibility on non-windows systems right now.

[cyyever]

We're moving towards cmake but it's going to take a while to get everything that autoconf does for us working in cmake... in the meantime thanks for both. The "make dist" job in Travis CI failed and it looks related.
AppVeyor passed,Travis CI failed for networking problems.

[jeking3]

fbthrift code changes would need to be submitted by the fbthrift team. We cannot pull them in.

[jeking3]

Please change the MSVC2017 build job in appveyor to build shared.

[jeking3]

Also rebase on master which is more stable... I fixed the concurrency_test.

[emmenlau]

Looking forward, thanks!

[cyyever]

Looking forward, thanks!

wait for a moment.

[cyyever]

Also rebase on master which is more stable... I fixed the concurrency_test.

just rebase on master.I am not familiar with appveyor scripts.

[jeking3]

In the file appveyor.yml there is a directive that sets the MSVC 2017 build to static. Change it. None of the windows MSVC build tested your changes because both of them disable shared library builds.

[cyyever]

In the file appveyor.yml there is a directive that sets the MSVC 2017 build to static. Change it. None of the windows MSVC build tested your changes because both of them disable shared library builds.

fixed

[ericu65]

This PR throws the following warning in MSVC:
warning LNK4049: locally defined symbol ?GlobalOutput@thrift@apache@@3VTOutput@12@A (class apache::thrift::TOutput apache::thrift::GlobalOutput) imported

[ericu65]

@cyyever @jeking3 note above is in regard to static libraries on MSVC 15.

[goorjn]

@cyyever @jeking3 wouldn't it have been more convenient to move the TSSLSocketFactory::setManualOpenSSLInitialization's body to cpp rather than explicitly exporting the variable ? (see https://stackoverflow.com/questions/2479784/exporting-static-data-in-a-dll)
Maybe there is a similar trick to avoid to have to explicitly export GlobalOutput variable, but I still haven't looked for it.
By the way, I would have preferred to have default static linking for windows, just like previous versions, rather than to have to #define THRIFT_STATIC_DEFINE in my projects to do so.

[Jens-G]

https://issues.apache.org/jira/browse/LEGAL-538