search

SOCI / soci

Official repository of the SOCI - The C++ Database Access Library
http://soci.sourceforge.net/
Boost Software License 1.0
1.37k stars 472 forks source link

Add bigobj to msvc compile flags #1124

Closed mkaes closed 3 months ago

mkaes commented 5 months ago

Adding /bigobj to the compile options fixes an error when trying to compile soci using VS 2019

vadz commented 4 months ago

Thanks for the fix! I wonder if we could do it tests/CMakeLists.txt instead, as it only affects the (huge, due to common-tests.h inclusion) source file there? I imagine using /bigobj has some drawbacks, even if I'm not sure what they're, as otherwise I don't know why it wouldn't be turned on by default.

mkaes commented 4 months ago

AFAIK there is not real drawback in enabling /bigobj. The only drawback that the documentation mentions is

Linkers that shipped prior to Visual C++ 2005 cannot read .obj files that were produced with /bigobj

So I guess it is ok to enable it for all files. Otherwise it must be enabled when needed for each file.

vadz commented 4 months ago

AFAIK there is not real drawback in enabling /bigobj.

A quick web search finds this SO answer which states that it results in a 2% size penalty for the object files using it. It's not a lot, but, still, why bloat SOCI objects size if it's only needed for the tests?

So I guess it is ok to enable it for all files. Otherwise it must be enabled when needed for each file.

Could it be enabled just in tests subdirectory as I suggested? If yes, this would be just as simple as doing it here and would be completely uncontroversial (who cares about the tests size...). Could you please test if that works? TIA!

mkaes commented 4 months ago

I enabled the option only for the tests. If other files show the same issue in the future they need to be added afterwards.

I personally find the 2% size penalty a little exaggerated and it is only for the object files. So basically it is only disk space during compile. That is the reason why I always use bigobj by default. Because as soon as you start using templates you will hit this issue.

Krzmbrzl commented 4 months ago

That is the reason why I always use bigobj by default. Because as soon as you start using templates you will hit this issue.

I can only second this statement. This is my approach as well. Besides, the size of object files should essentially be of no concern on this scale as modern hardware has more than enough disk space to fit in an extra 2% for bigger object files. The thing that you get for having smaller object files is that you'll eventually run into (seemingly odd) compiler errors eventually :shrug: