Marcel, please reconsider.
I think you jumped to some wrong assumptions. (Some are my fault, so understandable.)
adrian_broher wrote:I was sick of...
When I am complaining about things, that was mostly griping about the learning curve for CMake, and not knowing for FO what was intended and what was temporary. The former is necessary, and the latter is not your fault. (As you say, you've been making it better than when you found it.)
If I sound unappreciative, let me say I am glad the CMake-SDK scripts exist.
Getting all that to work, just for Xcode, would be a nightmare.
Now that I'm farther down the learning curve, and finding more of the comments on this forum, I have a better (but not complete) idea of what to do for the SDK.
adrian_broher wrote:None of your proposed changes solves an urgent problem or brings a significant improvement to the project or its workflow
Disagree.
It may only affect the Mac users, but there are still problems (that would not be obvious to Windows users).
First, the Logger system does not work for the Mac.
Tracking down bugs is a lot easier when it is working as intended.
Second, we want the
visibility=hidden to reduce chances of code mistakes.
That should be done in the SDK also. If we don't, we have hundreds of warnings in the FO Travis check, which can hide real problems.
According to the Boost documentation, the Boost Log libraries should be shared, not static. I'm hoping that will fix the Logger situation for the Mac build. Maybe, maybe not, but I won't know until I get that working.
adrian_broher wrote:Anything that prolongs the lifetime of the xcode or msvc project, everything that doesn't directly support the outright removal of those components in favour of cmake...
For the SDK, I am
only using CMake.
I've mentioned that a few times already.
(Not even touching Xcode for the SDK build. That will be hopelessly left behind.)
Now that I've learned the basics of CMake, any proposed changes to the FO build will be for both Xcode and CMakeLists.txt. (I should have stated that earlier.)
I'm using XCode to get something that works. (Easier for me to work in that environment.)
Once I have an Xcode solution, I won't submit a PR until that is duplicated for CMake.
adrian_broher wrote:I won't support multiple build systems just for somebody else convenience of not using CMake and hampering the overall project quality.
See last point.
adrian_broher wrote:For the patch you suggested the obvious answer is "No" as it would break any other platform for boost.
Thank you for clarifying that.
Completely valid.
I was looking for a quick fix, since I didn't have enough Boost and CMake knowledge at the time.
Since I am proposing switching Boost from static to shared libs for the Mac (for Boost Log), those particular patches are no longer necessary.
I'm farther on the learning curve.
The "new" patches will be in a format that could be absorbed by the Boost repository. (I intend to submit them to Boost when I get caught up, or maybe I'll find an existing commit like I did for log/detail/setup_config.hpp.) The changes will only be for the (setup) files that have Windows-specific solutions only, to extend the same behavior for the Mac build.
adrian_broher wrote:Problem being now that I won't unfreeze the current SDK setup until FreeOrion has a unified build setup because I won't do work three times (reconfigure and test msvc, xcode and cmake with perstering multiple devs) when I can go away with doing it once (cmake only) (
PR #1455)(
PR #1416).
Your comments are very useful.
I'm glad to hear all of your comments now, so I will make fewer mistakes for future PR changes.
My current SDK PR is dead in the water.
It is a placeholder, until I get everything working from beginning to end. (I will edit my comment to reflect that.)
Any changes I am working on now will only affect the Mac build.
(There is one thing I'd like to do for both Mac and Windows builds, but I will start a new forum topic and make a different PR.)