You won't gain much with such a change; out of my head (which does not reflect the latest 1,5 month of development) the result would be:

atomic -- must be kept, as it is an implicit dependency of boost::thread and boost::logcontainer -- must be kept, as is an implicit dependency of boost::threadexception -- must be kept, as is an implicit dependency of boost::threadgraph -- must be kept, as is used by universe/Pathfinder.cpp to find fleet routes.math -- I don't know, but probably some boost internals rely on this and it implements some useful code like quats.program_options -- can be disabledrandom -- must be kept, as it is used by util/Random.h, unless that custom random generator PR was merged (which I hope it wasn't).test -- must be kept, as it is used by the existing and future automated tests.timer -- must be kept, as it is used at various places within FO to take time for logging purposes.

Thanks for your reply. I'll look through the code, in case any of those situations have changed.

adrian_broher wrote:

atomic -- must be kept, as it is an implicit dependency of boost::thread and boost::logcontainer -- must be kept, as is an implicit dependency of boost::threadexception -- must be kept, as is an implicit dependency of boost::thread

At least for these, I called "otool -L" on the thread and log shared libraries.Is there something else I should be checking?

I didn't see them depending on atomic, container, or exception."thread" needed: system"log" needed: chrono, date_time, filesystem, regex, thread, and system

I've run (my modified version of) the CMake SDK with all the library builds mentioned dropped.I don't know (yet) if the libraries are fully functional, but the script completed the build without error.I would have thought that implicit dependencies would create an error during the build?

I've run (my modified version of) the CMake SDK with all the library builds mentioned dropped.I don't know (yet) if the libraries are fully functional, but the script completed the build without error.

Then it is not a viable benchmark for checking if the libraries are required or not. Unless the build sucessfully builds on all platforms that consume the SDK.

Quote:

I would have thought that implicit dependencies would create an error during the build?

No, especially if the dependencies are within the headers only. Unless the headers are included during the build into a compilation unit and the compiler can't locate the missing header the SDK build is not able to tell you that it is incomplete. Only building freeorion itself can tell you that.

No, especially if the dependencies are within the headers only. Unless the headers are included during the build into a compilation unit and the compiler can't locate the missing header the SDK build is not able to tell you that it is incomplete. Only building freeorion itself can tell you that.

Ah, thanks.I forgot that all of the include files are unpacked and available, even if the library building is skipped.

Request withdrawn.

You mentioned that we might be able to drop program_options or math, but I will try the entire path (SDK through running FO) as a check first.

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum