New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Logger system is currently broken #1575

Closed
memem359 opened this Issue May 16, 2017 · 56 comments

Comments

Projects
None yet
8 participants
@memem359
Contributor

memem359 commented May 16, 2017

Environment

  • FreeOrion Version: Running with the default settings. (Trashed old config files to let the game create one, and started a game with the initial settings.)
  • Operating System: MacOSX
  • Fetched as
    • Weekly development build (May 16), but I've been seeing the same behavior the past few weeks when building from (master) source.

Description

More work needs to be done after the recent logger system PR changes, as it is broken enough to not be useful.

  • Currently, the only logger behaving as it should is InfoLogger(log). Those messages (being sent from Logger.cpp, mostly line 286) are the only things I see in the AI and freeorion logs, and it is only for the initial logger threshold settings.

  • I tried running from the command line and redirecting standard output to a file. All of the other expected log messages are being sent there (from all the clients), and the file sender is not being converted to human readable format. As an example:
    [2017-05-16 13:59:42.399184] [0xa6f311c0] [info] ProductionQueue::Update: Simulating future turns of production queue

  • After loading the hotkey settings and various ship part names, there are 220 lines of messages complaining about config.xml options. As an example: [2017-05-16 13:57:42.443918] [0xa6f311c0] [info] Option "UI.windows.design.base-selector.left", was in config.xml but was not recognized. It may not be registered yet or you may need to delete your config.xml if it is out of date.
    Since this is the default file created by the game, the default values should be updated. (I think a search for db.Add will find the necessary code.)
    The unrecognized options are: UI.windows.* , app-* (height, left, top, width), logging.execs.* , and logging.sources.*

@memem359 memem359 changed the title from Logger system is currently broken to Logger system is currently broken (Mac OSX) May 16, 2017

@LGM-Doyle

This comment has been minimized.

Show comment
Hide comment
@LGM-Doyle

LGM-Doyle May 17, 2017

Contributor

@memem359 thanks for reporting this issue.

Could you provide the following to help me debug this issue: the log files freeorion.log, freeoriond.log, AI_X.logs and the file with the re-directed std::out.

What version of OSX are you on?
What version of clang did you compile with?
What version of boost::log did you link to?

thanks.

Contributor

LGM-Doyle commented May 17, 2017

@memem359 thanks for reporting this issue.

Could you provide the following to help me debug this issue: the log files freeorion.log, freeoriond.log, AI_X.logs and the file with the re-directed std::out.

What version of OSX are you on?
What version of clang did you compile with?
What version of boost::log did you link to?

thanks.

@memem359

This comment has been minimized.

Show comment
Hide comment
@memem359

memem359 May 17, 2017

Contributor

MacOSX 10.12.5 ("Sierra", latest version)

I am using the weekly test build provided by Vezzra (build 2017-05-16.18e65e5).
I only mentioned that I had seen this kind of behavior in my local builds for a few weeks, in case there was concern that it was specifically this released test build.

Specific steps:

  1. Make sure all old log and config files were deleted.
  2. Start game from command line: FreeOrion.app/Contents/MacOS/Freeorion >~/Desktop/std_out.txt 2>~/Desktop/std_err.txt
  3. Single Player, reduced AI players to 2, then started. (Left the seed at 0.)
  4. End Turn (no other actions taken) to get to turn 2, then Resign, and Exit

The std::cerr file is empty. I added ".txt" to the log files, only so I could add them to this post.
std_out.txt
freeorion_log.txt
freeoriond_log.txt
AI_1_log.txt
AI_2_log.txt

I should add that if I change all the log thresholds to "trace" in the options, I get a bunch of [trace] effects messages in the freeorion.log (many MB of them). But the other messages were still being sent to std::out.

Contributor

memem359 commented May 17, 2017

MacOSX 10.12.5 ("Sierra", latest version)

I am using the weekly test build provided by Vezzra (build 2017-05-16.18e65e5).
I only mentioned that I had seen this kind of behavior in my local builds for a few weeks, in case there was concern that it was specifically this released test build.

Specific steps:

  1. Make sure all old log and config files were deleted.
  2. Start game from command line: FreeOrion.app/Contents/MacOS/Freeorion >~/Desktop/std_out.txt 2>~/Desktop/std_err.txt
  3. Single Player, reduced AI players to 2, then started. (Left the seed at 0.)
  4. End Turn (no other actions taken) to get to turn 2, then Resign, and Exit

The std::cerr file is empty. I added ".txt" to the log files, only so I could add them to this post.
std_out.txt
freeorion_log.txt
freeoriond_log.txt
AI_1_log.txt
AI_2_log.txt

I should add that if I change all the log thresholds to "trace" in the options, I get a bunch of [trace] effects messages in the freeorion.log (many MB of them). But the other messages were still being sent to std::out.

@LGM-Doyle

This comment has been minimized.

Show comment
Hide comment
@LGM-Doyle

LGM-Doyle May 17, 2017

Contributor

@memem359 thanks for the files.

I can't replicate the problem, but I am running linux.

When you turn on "trace" are the log messages in the files still only for the log logger, or do other loggers show up but only at the trace level? If so which other loggers show up?

@Vezzra do you know if this problem is happening with all OSX systems?

Contributor

LGM-Doyle commented May 17, 2017

@memem359 thanks for the files.

I can't replicate the problem, but I am running linux.

When you turn on "trace" are the log messages in the files still only for the log logger, or do other loggers show up but only at the trace level? If so which other loggers show up?

@Vezzra do you know if this problem is happening with all OSX systems?

@memem359

This comment has been minimized.

Show comment
Hide comment
@memem359

memem359 May 17, 2017

Contributor

Yeah, I was hoping to hear if any of the other Mac users had noticed this as well.
Otherwise, it will be up to me. :-b

When I turn on "trace", this is what I notice:

  • Lots of TraceLogger(effects) messages in all the logs (AI, freeorion, and freeoriond). As an example, messages like Universe.cpp line 965.
  • There should be TraceLogger(network) messages from ClientNetworking.cpp. They are labeled as [info] instead of [trace] network, and wind up in standard out.
  • Appears that all other loggers are also showing up as "info" in the standard out. This includes TraceLogger(), like from Building.cpp line 323, and a variety of Debug-level statements.

I suspect I will have to stuff some std::cerr statements into the Logger.cpp, to see what is going on (now that I know how to get the standard error output from a Mac app).

@LGM-Doyle : Should I be looking through Logger.cpp, or LoggerWithOptionsDB.cpp (or both)?

Contributor

memem359 commented May 17, 2017

Yeah, I was hoping to hear if any of the other Mac users had noticed this as well.
Otherwise, it will be up to me. :-b

When I turn on "trace", this is what I notice:

  • Lots of TraceLogger(effects) messages in all the logs (AI, freeorion, and freeoriond). As an example, messages like Universe.cpp line 965.
  • There should be TraceLogger(network) messages from ClientNetworking.cpp. They are labeled as [info] instead of [trace] network, and wind up in standard out.
  • Appears that all other loggers are also showing up as "info" in the standard out. This includes TraceLogger(), like from Building.cpp line 323, and a variety of Debug-level statements.

I suspect I will have to stuff some std::cerr statements into the Logger.cpp, to see what is going on (now that I know how to get the standard error output from a Mac app).

@LGM-Doyle : Should I be looking through Logger.cpp, or LoggerWithOptionsDB.cpp (or both)?

@dbenage-cx

This comment has been minimized.

Show comment
Hide comment
@dbenage-cx

dbenage-cx May 17, 2017

Member

Borrowed a mac(10.11) and can confirm using same test build, so not specific to one setup.

Member

dbenage-cx commented May 17, 2017

Borrowed a mac(10.11) and can confirm using same test build, so not specific to one setup.

@dbenage-cx dbenage-cx added this to the v0.4.8 milestone May 17, 2017

@memem359

This comment has been minimized.

Show comment
Hide comment
@memem359

memem359 May 17, 2017

Contributor

@dbenage-cx : That's great! Well... terrible, but misery loves company.

Maybe this will shed more light. Has me confused.

Since I know the TraceLogger(effects) works, I put this into Empire.cpp
TraceLogger(effects) << "Empire Death Star dumping message";
The editor gives me an error message: use of undeclared identifier "fo_logger_global_effects"; did you mean "fo_logger_global_"?

(If I follow the editor's suggestion to use "fo_logger_global_TraceLogger" instead of "TraceLogger", it then complains about undeclared identifier "effects".)

Weird how the macro works fine for Universe.cpp, but not-quite-right for Empire.cpp.

Contributor

memem359 commented May 17, 2017

@dbenage-cx : That's great! Well... terrible, but misery loves company.

Maybe this will shed more light. Has me confused.

Since I know the TraceLogger(effects) works, I put this into Empire.cpp
TraceLogger(effects) << "Empire Death Star dumping message";
The editor gives me an error message: use of undeclared identifier "fo_logger_global_effects"; did you mean "fo_logger_global_"?

(If I follow the editor's suggestion to use "fo_logger_global_TraceLogger" instead of "TraceLogger", it then complains about undeclared identifier "effects".)

Weird how the macro works fine for Universe.cpp, but not-quite-right for Empire.cpp.

@dbenage-cx

This comment has been minimized.

Show comment
Hide comment
@dbenage-cx

dbenage-cx May 18, 2017

Member

@memem359 The named logger effects is not defined in Empire.cpp, but is in Universe.cpp, your IDE gives a similar message to mine.
Might try declaring and using another named logger, or changing one TraceLogger(effects) to ErrorLogger(effects).
Not sure what is special about effects as others like FSM are sent to std out as well.

Setting all severities to trace except for effects has same output as initial logs. With all at trace, I only note additions for [trace] effects :.
all_except_effects_trace.txt
all_trace.log.txt

Edit: Any possibility related to visibility? (excerpt from travis build - linking commonlib):

ld: warning: direct access in boost::log::v2s_mt_posix::core::reset_filter() to global weak symbol boost::log::v2s_mt_posix::aux::light_function<bool (boost::log::v2s_mt_posix::attribute_value_set const&)>::impl<boost::log::v2s_mt_posix::filter::default_filter>::destroy_impl(void*) means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
Member

dbenage-cx commented May 18, 2017

@memem359 The named logger effects is not defined in Empire.cpp, but is in Universe.cpp, your IDE gives a similar message to mine.
Might try declaring and using another named logger, or changing one TraceLogger(effects) to ErrorLogger(effects).
Not sure what is special about effects as others like FSM are sent to std out as well.

Setting all severities to trace except for effects has same output as initial logs. With all at trace, I only note additions for [trace] effects :.
all_except_effects_trace.txt
all_trace.log.txt

Edit: Any possibility related to visibility? (excerpt from travis build - linking commonlib):

ld: warning: direct access in boost::log::v2s_mt_posix::core::reset_filter() to global weak symbol boost::log::v2s_mt_posix::aux::light_function<bool (boost::log::v2s_mt_posix::attribute_value_set const&)>::impl<boost::log::v2s_mt_posix::filter::default_filter>::destroy_impl(void*) means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
@memem359

This comment has been minimized.

Show comment
Hide comment
@memem359

memem359 May 18, 2017

Contributor

Ah, thanks for pointing out DeclareThreadSafeLogger(effects).
I should have read line 99 of Logger.h more carefully.

Contributor

memem359 commented May 18, 2017

Ah, thanks for pointing out DeclareThreadSafeLogger(effects).
I should have read line 99 of Logger.h more carefully.

@LGM-Doyle

This comment has been minimized.

Show comment
Hide comment
@LGM-Doyle

LGM-Doyle May 18, 2017

Contributor

@memem359 the reason that I asked if turning on "trace" only showed the log messages, is that the log logger is the only logger compiled in the same compilation unit as the file sink configuration. I suspected a linker problem with the other loggers.

@dbenage-cx's sleuthing in the travis build files indicates that the problem is mismatched object file visibilities.

Looking in the XCode project file it is clear that the -fvisibility=hidden option is sometimes used as a link option and sometimes as a compile option. This is why the effects logger works. It should be a compile option, applied to all compilation units.

I don't have access to XCode, so it will be difficult for me to provide a patch. If someone with access to XCode could change the project file so that the -fvisibility=hidden option is used with all compilation units, then I think that will fix the problem, or at least provide new errors messages.

Thanks.

Contributor

LGM-Doyle commented May 18, 2017

@memem359 the reason that I asked if turning on "trace" only showed the log messages, is that the log logger is the only logger compiled in the same compilation unit as the file sink configuration. I suspected a linker problem with the other loggers.

@dbenage-cx's sleuthing in the travis build files indicates that the problem is mismatched object file visibilities.

Looking in the XCode project file it is clear that the -fvisibility=hidden option is sometimes used as a link option and sometimes as a compile option. This is why the effects logger works. It should be a compile option, applied to all compilation units.

I don't have access to XCode, so it will be difficult for me to provide a patch. If someone with access to XCode could change the project file so that the -fvisibility=hidden option is used with all compilation units, then I think that will fix the problem, or at least provide new errors messages.

Thanks.

@Dilvish-fo Dilvish-fo changed the title from Logger system is currently broken (Mac OSX) to Logger system is currently broken May 18, 2017

@Dilvish-fo

This comment has been minimized.

Show comment
Hide comment
@Dilvish-fo

Dilvish-fo May 18, 2017

Member

This is not just a MacOSX issue. I'm on Linux and I just sat down to try doing some AI work, and I am finding the AI logs effectively empty, nothing more than a few initial lines about logging supposedly being set up. I see that my server and client logs are similarly nearly-empty.

This is a really serious issue. I can't do any significant AI work like this. Since this has been noted for at least a couple days and there does not appear to be a ready fix, I think that the logging changes need to be reverted while a fix is worked on.

Member

Dilvish-fo commented May 18, 2017

This is not just a MacOSX issue. I'm on Linux and I just sat down to try doing some AI work, and I am finding the AI logs effectively empty, nothing more than a few initial lines about logging supposedly being set up. I see that my server and client logs are similarly nearly-empty.

This is a really serious issue. I can't do any significant AI work like this. Since this has been noted for at least a couple days and there does not appear to be a ready fix, I think that the logging changes need to be reverted while a fix is worked on.

@LGM-Doyle

This comment has been minimized.

Show comment
Hide comment
@LGM-Doyle

LGM-Doyle May 18, 2017

Contributor

@Dilvish-fo, there is a fix for OSX. Someone needs to open Xcode and add -fvisibility=hidden to the compilation units in the project file.

The compile options in the travis log that shows the problem are the compile options from the Xcode project and not the CMakeList.txt, so it seems like that is the problem.

If you are not using the XCode project file to direct your build, then that problem can't be the same problem that you are experiencing.

Could you post your logs, freeorion.log, freeoriond.log, the AI_X.log and the console messages if it is dumping to console so that I can begin looking at your issue?

Contributor

LGM-Doyle commented May 18, 2017

@Dilvish-fo, there is a fix for OSX. Someone needs to open Xcode and add -fvisibility=hidden to the compilation units in the project file.

The compile options in the travis log that shows the problem are the compile options from the Xcode project and not the CMakeList.txt, so it seems like that is the problem.

If you are not using the XCode project file to direct your build, then that problem can't be the same problem that you are experiencing.

Could you post your logs, freeorion.log, freeoriond.log, the AI_X.log and the console messages if it is dumping to console so that I can begin looking at your issue?

@memem359

This comment has been minimized.

Show comment
Hide comment
@memem359

memem359 May 18, 2017

Contributor

It might be a deeper problem, that depends on the compiler. I found this entry:
stackoverflow - clang fvisibility hidden
... and it sounds like GCC is letting through some poor behavior that Clang is not.

@LGM-Doyle : I will probably need more guidance. I'll take a look at CMakeLists.txt, and get the Xcode settings to match what I see there. But for now, I'm confused about what the code should be doing.

In Xcode, I see an overall project setting, and 10 targets: Configure, GG, Parse, Common, ClientCommon, FreeOrionServer, FreeOrionClient, FreeOrionAI, FreeOrion, and MakeDMG. I go to "Apple LLVM 8.1 Custom Compiler Flags: Other C++ Flags". Right now, only Parse has the "-fvisibility=hidden" flag.

If I add that flag to GG, Common, and ClientCommon, then when it builds the clients (like FreeOrionServer), I get a spew of "missing symbol" errors.

Looking at Export.h has me confused.

#if FREEORION_BUILD_COMMON && __ GNUC __
#d efine FO_COMMON_API __ attribute __(( __ visibility __("default")))
#else
#d efine FO_COMMON_API
#endif

(I had to put in a space in "d efine" and the underlines to avoid weird font behavior in this post.)

So right now, FO_COMMON_API isn't doing anything at all?
If I set the visibility to hidden, then everything inside Common is locked away from the rest of the build, right?

That's also true for FO_PARSE_API (if it isn't GNU compiler, the define is blank).

Contributor

memem359 commented May 18, 2017

It might be a deeper problem, that depends on the compiler. I found this entry:
stackoverflow - clang fvisibility hidden
... and it sounds like GCC is letting through some poor behavior that Clang is not.

@LGM-Doyle : I will probably need more guidance. I'll take a look at CMakeLists.txt, and get the Xcode settings to match what I see there. But for now, I'm confused about what the code should be doing.

In Xcode, I see an overall project setting, and 10 targets: Configure, GG, Parse, Common, ClientCommon, FreeOrionServer, FreeOrionClient, FreeOrionAI, FreeOrion, and MakeDMG. I go to "Apple LLVM 8.1 Custom Compiler Flags: Other C++ Flags". Right now, only Parse has the "-fvisibility=hidden" flag.

If I add that flag to GG, Common, and ClientCommon, then when it builds the clients (like FreeOrionServer), I get a spew of "missing symbol" errors.

Looking at Export.h has me confused.

#if FREEORION_BUILD_COMMON && __ GNUC __
#d efine FO_COMMON_API __ attribute __(( __ visibility __("default")))
#else
#d efine FO_COMMON_API
#endif

(I had to put in a space in "d efine" and the underlines to avoid weird font behavior in this post.)

So right now, FO_COMMON_API isn't doing anything at all?
If I set the visibility to hidden, then everything inside Common is locked away from the rest of the build, right?

That's also true for FO_PARSE_API (if it isn't GNU compiler, the define is blank).

@Morlic-fo

This comment has been minimized.

Show comment
Hide comment
@Morlic-fo

Morlic-fo May 18, 2017

Contributor

I'm on Linux and I just sat down to try doing some AI work, and I am finding the AI logs effectively empty, nothing more than a few initial lines about logging supposedly being set up

Just to be sure: Did you set the Logging level to at least debug via the options screen ingame? That was required for me (Win7) as the default logging level was the (currently completely useless) info.

Contributor

Morlic-fo commented May 18, 2017

I'm on Linux and I just sat down to try doing some AI work, and I am finding the AI logs effectively empty, nothing more than a few initial lines about logging supposedly being set up

Just to be sure: Did you set the Logging level to at least debug via the options screen ingame? That was required for me (Win7) as the default logging level was the (currently completely useless) info.

@LGM-Doyle

This comment has been minimized.

Show comment
Hide comment
@LGM-Doyle

LGM-Doyle May 18, 2017

Contributor

@memem359 here is the current clang documentation on visibility.

From the error message that @dbenage-cx uncovered it looks like all of the compilation units need to be -fvisibility=hidden.

And in Export.h you will have to add && defined(FREEORION_MACOSX)

What we are trying to do is satisfy the error message, which says that all compiliation units should be compiled with the same visibility settings.

Contributor

LGM-Doyle commented May 18, 2017

@memem359 here is the current clang documentation on visibility.

From the error message that @dbenage-cx uncovered it looks like all of the compilation units need to be -fvisibility=hidden.

And in Export.h you will have to add && defined(FREEORION_MACOSX)

What we are trying to do is satisfy the error message, which says that all compiliation units should be compiled with the same visibility settings.

@LGM-Doyle

This comment has been minimized.

Show comment
Hide comment
@LGM-Doyle

LGM-Doyle May 18, 2017

Contributor

What @Morlic-fo said.

Has everyone having problems set the thresholds of the errors that you want to see to debug?

There are not a lot of error messages at the default info level.

Contributor

LGM-Doyle commented May 18, 2017

What @Morlic-fo said.

Has everyone having problems set the thresholds of the errors that you want to see to debug?

There are not a lot of error messages at the default info level.

@dbenage-cx

This comment has been minimized.

Show comment
Hide comment
@dbenage-cx

dbenage-cx May 18, 2017

Member

For the log files I posted, I ensured logging was set to either debug or trace.

Does apples version of clang not define __GNUC__ (I've read that normal clang does)?

Member

dbenage-cx commented May 18, 2017

For the log files I posted, I ensured logging was set to either debug or trace.

Does apples version of clang not define __GNUC__ (I've read that normal clang does)?

@memem359

This comment has been minimized.

Show comment
Hide comment
@memem359

memem359 May 18, 2017

Contributor

Right now, I am compiling (MacOSX) with the visibility=hidden flag for all compilation and a bunch of Xcode project corrections.

I also changed parse/parse.h and util/export.h, so that instead of checking for __ GNUC __, I changed that to !defined FREEORION_WIN32. (Are there Windows builds besides WIN32?) If @Dilvish-fo is using a non-GCC compiler, this might help.

I don't know if it will fix the logger problems, but so far it has compiled without error.
I'll report more after I have time to try a test game. (Gotta run!)

Contributor

memem359 commented May 18, 2017

Right now, I am compiling (MacOSX) with the visibility=hidden flag for all compilation and a bunch of Xcode project corrections.

I also changed parse/parse.h and util/export.h, so that instead of checking for __ GNUC __, I changed that to !defined FREEORION_WIN32. (Are there Windows builds besides WIN32?) If @Dilvish-fo is using a non-GCC compiler, this might help.

I don't know if it will fix the logger problems, but so far it has compiled without error.
I'll report more after I have time to try a test game. (Gotta run!)

@memem359

This comment has been minimized.

Show comment
Hide comment
@memem359

memem359 May 18, 2017

Contributor

Quick update... Much better!
I went back to the clean-default settings (debug level).
The AI logs now have messages from [debug] ai , freeoriond.log has [debug] server, and freeorion.log has [debug] client
I will try to get a PR ready by tomorrow.

The std::cout is still being flooded with messages, but that investigation can wait for another day.

I want to try reverting my changes to parse.h and export.h, to verify if these are necessary, or if some other change I made to the Xcode project file made the difference.

Thanks to everyone on this issue.
I would not have tried the visibility compiler flag, until it was mentioned here.

Contributor

memem359 commented May 18, 2017

Quick update... Much better!
I went back to the clean-default settings (debug level).
The AI logs now have messages from [debug] ai , freeoriond.log has [debug] server, and freeorion.log has [debug] client
I will try to get a PR ready by tomorrow.

The std::cout is still being flooded with messages, but that investigation can wait for another day.

I want to try reverting my changes to parse.h and export.h, to verify if these are necessary, or if some other change I made to the Xcode project file made the difference.

Thanks to everyone on this issue.
I would not have tried the visibility compiler flag, until it was mentioned here.

@LGM-Doyle

This comment has been minimized.

Show comment
Hide comment
@LGM-Doyle

LGM-Doyle May 18, 2017

Contributor

@memem359 thanks for doing that work. I look forward to your update.

Some messages will still be dumped to console. The logging system works during static initialization and all log messages before the file logging is initialized are sent to the console so that they won't be lost in the event a crash during static initialization.

The "Option "X", was in config.xml but was not recognized" messages are not an issue.

They should probably be removed.

The original assumption of the OptionsDB code was that all options would be setup during static initialization. That message is how OptionsDB states that an option is in the XML file, but has not already been initialized by the game code at the time that the XML file is parsed.

Usage has changed and many options are not initialized during static initialization. That is a good change.

The XML file has to be parsed before the logger files are initialized to get the file names and the logger options. Hence any logging at that time is dumped to the console, so that it is not lost.

The message used to be hidden by the verbose-logging switch. Now it is no longer hidden.

Contributor

LGM-Doyle commented May 18, 2017

@memem359 thanks for doing that work. I look forward to your update.

Some messages will still be dumped to console. The logging system works during static initialization and all log messages before the file logging is initialized are sent to the console so that they won't be lost in the event a crash during static initialization.

The "Option "X", was in config.xml but was not recognized" messages are not an issue.

They should probably be removed.

The original assumption of the OptionsDB code was that all options would be setup during static initialization. That message is how OptionsDB states that an option is in the XML file, but has not already been initialized by the game code at the time that the XML file is parsed.

Usage has changed and many options are not initialized during static initialization. That is a good change.

The XML file has to be parsed before the logger files are initialized to get the file names and the logger options. Hence any logging at that time is dumped to the console, so that it is not lost.

The message used to be hidden by the verbose-logging switch. Now it is no longer hidden.

@Dilvish-fo

This comment has been minimized.

Show comment
Hide comment
@Dilvish-fo

Dilvish-fo May 18, 2017

Member

Just to be sure: Did you set the Logging level to at least debug via the options screen ingame? That was required for me (Win7) as the default logging level was the (currently completely useless) info.

@Morlic-fo thanks for the suggestion; that does at least appear to have cleared up the problem.

@LGM-Doyle is there any objection to putting in a commit setting the default log levels to debug so that we don't have to reset those after every time we recompile or take other actions to get logging. master is a development branch and it seems appropriate to me that our default level of logging is something more than practically-nothing. I suppose it should be possible for me to put something into persistent-config for my own personal testing, but for all our playtesters out there I really think that the default logging should be at debug.

Member

Dilvish-fo commented May 18, 2017

Just to be sure: Did you set the Logging level to at least debug via the options screen ingame? That was required for me (Win7) as the default logging level was the (currently completely useless) info.

@Morlic-fo thanks for the suggestion; that does at least appear to have cleared up the problem.

@LGM-Doyle is there any objection to putting in a commit setting the default log levels to debug so that we don't have to reset those after every time we recompile or take other actions to get logging. master is a development branch and it seems appropriate to me that our default level of logging is something more than practically-nothing. I suppose it should be possible for me to put something into persistent-config for my own personal testing, but for all our playtesters out there I really think that the default logging should be at debug.

@memem359

This comment has been minimized.

Show comment
Hide comment
@memem359

memem359 May 19, 2017

Contributor

When I run with the default (no previous config or persistent_config), all the levels are "debug". Is that only true for Mac OSX?

Contributor

memem359 commented May 19, 2017

When I run with the default (no previous config or persistent_config), all the levels are "debug". Is that only true for Mac OSX?

@geoffthemedio

This comment has been minimized.

Show comment
Hide comment
@geoffthemedio

geoffthemedio May 19, 2017

Member

Defaults to "info" for me on Windows.

Member

geoffthemedio commented May 19, 2017

Defaults to "info" for me on Windows.

@LGM-Doyle

This comment has been minimized.

Show comment
Hide comment
@LGM-Doyle

LGM-Doyle May 19, 2017

Contributor

I have no objections to any particular choice of default log threshold.

It currently defaults to debug for the Debug build and info for the Release build. @memem359 I think that you have built a Debug build.

I assumed that devs developed with the Debug build.

I also assumed that devs used a persistent_config.xml file. @dbenage-cx's pending PR adds a button to create a persistent config file from current settings, so in future using a persistent_config.xml will be simpler. The persistent config is the location for storing configuration that a user wants to persistent between builds, not just between games, which is usually what a given dev's log level thresholds would be.

The Release build for normal non-tester players should have the default logging threshold set to info. Otherwise the logs get large enough to negatively affect game performance.

The weekly test builds for testers should have the default log threshold set to debug.

If we want the build for testers to have the performance of a Release build, but the debugging information and log threshold settings of a Debug build, perhaps we should start using the cmake build type RelWithDebInfo to indicate a tester build.

Contributor

LGM-Doyle commented May 19, 2017

I have no objections to any particular choice of default log threshold.

It currently defaults to debug for the Debug build and info for the Release build. @memem359 I think that you have built a Debug build.

I assumed that devs developed with the Debug build.

I also assumed that devs used a persistent_config.xml file. @dbenage-cx's pending PR adds a button to create a persistent config file from current settings, so in future using a persistent_config.xml will be simpler. The persistent config is the location for storing configuration that a user wants to persistent between builds, not just between games, which is usually what a given dev's log level thresholds would be.

The Release build for normal non-tester players should have the default logging threshold set to info. Otherwise the logs get large enough to negatively affect game performance.

The weekly test builds for testers should have the default log threshold set to debug.

If we want the build for testers to have the performance of a Release build, but the debugging information and log threshold settings of a Debug build, perhaps we should start using the cmake build type RelWithDebInfo to indicate a tester build.

@memem359

This comment has been minimized.

Show comment
Hide comment
@memem359

memem359 May 19, 2017

Contributor

I think the Xcode project file changes in the PR will restore enough functionality that I can use the logger again.

I'm still seeing some odd behavior from the logger.
These might not have been noticed before, so it would be helpful to check if you are seeing this, and not assume that it is Mac-specific. :)

I ran with the loggers at Trace threshold, and redirected standard output to a text file. This behavior is for regular turn play, so is not about pre-logger-initialized messages.

  • TraceLogger(FSM) and TraceLogger(network) are still going to standard out. I did a grep for "HumanClientFSM" (messages from HumanClientFSM.cpp) and "ClientNetworking" (ClientNetworking.cpp), and those messages were absent in the *.log files and only in the stdout.

  • All of the python output (which should be redirected by the LoggerWrapper) are going to stdout. I used the phrase "new best design" when grep-ing the log and txt files.

Contributor

memem359 commented May 19, 2017

I think the Xcode project file changes in the PR will restore enough functionality that I can use the logger again.

I'm still seeing some odd behavior from the logger.
These might not have been noticed before, so it would be helpful to check if you are seeing this, and not assume that it is Mac-specific. :)

I ran with the loggers at Trace threshold, and redirected standard output to a text file. This behavior is for regular turn play, so is not about pre-logger-initialized messages.

  • TraceLogger(FSM) and TraceLogger(network) are still going to standard out. I did a grep for "HumanClientFSM" (messages from HumanClientFSM.cpp) and "ClientNetworking" (ClientNetworking.cpp), and those messages were absent in the *.log files and only in the stdout.

  • All of the python output (which should be redirected by the LoggerWrapper) are going to stdout. I used the phrase "new best design" when grep-ing the log and txt files.

@memem359

This comment has been minimized.

Show comment
Hide comment
@memem359

memem359 May 21, 2017

Contributor

I turned off the -fvisibility=hidden switch.
A lot less boost warnings during the build (still a bunch for Common), but I didn't notice any change in the logger behavior.

Since the logger is working enough that I can use it to debug other problems, I'll give this issue a lower priority, unless more clues appear. (I can try building Boost libraries with the same compiler flags, then doing all the work for a fresh build, but that won't happen anytime soon.)

Contributor

memem359 commented May 21, 2017

I turned off the -fvisibility=hidden switch.
A lot less boost warnings during the build (still a bunch for Common), but I didn't notice any change in the logger behavior.

Since the logger is working enough that I can use it to debug other problems, I'll give this issue a lower priority, unless more clues appear. (I can try building Boost libraries with the same compiler flags, then doing all the work for a fresh build, but that won't happen anytime soon.)

@LGM-Doyle

This comment has been minimized.

Show comment
Hide comment
@LGM-Doyle

LGM-Doyle May 22, 2017

Contributor

Thanks for doing the work and coming up with the PR.

Contributor

LGM-Doyle commented May 22, 2017

Thanks for doing the work and coming up with the PR.

LGM-Doyle added a commit to LGM-Doyle/freeorion that referenced this issue May 28, 2017

Remove all Logger(X) declarations from anonymous namespaces.
This is intended to change the linker behavior on OSX which is only
linking some of the loggers.

See issue freeorion#1575.
@LGM-Doyle

This comment has been minimized.

Show comment
Hide comment
@LGM-Doyle

LGM-Doyle May 28, 2017

Contributor

@memem359 I have added a PR that moves the declaration of the named loggers out of anonymous namespaces and into file scope. It does not change anything on linux for either clang or gcc.

Hopefully the change in visibility will trigger different warnings in the clang linker on OSX, with the libraries as compiled in the SDK.

Contributor

LGM-Doyle commented May 28, 2017

@memem359 I have added a PR that moves the declaration of the named loggers out of anonymous namespaces and into file scope. It does not change anything on linux for either clang or gcc.

Hopefully the change in visibility will trigger different warnings in the clang linker on OSX, with the libraries as compiled in the SDK.

@memem359

This comment has been minimized.

Show comment
Hide comment
@memem359

memem359 May 28, 2017

Contributor

@LGM-Doyle I didn't notice a change for my system either.

I'll look into this some more, focusing on the "HumanClientFSM" messages that are still going to stdout. If I can figure that one out, that will probably fix everything else (except maybe the python output).

Edit: I do have a question about the logging system. I noticed that, except for the base "log", that RegisterLoggerWithOptionsDB is only called from HumanClientApp.cpp. Is there an easy way to tell if a logger is using the LoggerWithOptions code or instead using Logger code?

Contributor

memem359 commented May 28, 2017

@LGM-Doyle I didn't notice a change for my system either.

I'll look into this some more, focusing on the "HumanClientFSM" messages that are still going to stdout. If I can figure that one out, that will probably fix everything else (except maybe the python output).

Edit: I do have a question about the logging system. I noticed that, except for the base "log", that RegisterLoggerWithOptionsDB is only called from HumanClientApp.cpp. Is there an easy way to tell if a logger is using the LoggerWithOptions code or instead using Logger code?

@LGM-Doyle

This comment has been minimized.

Show comment
Hide comment
@LGM-Doyle

LGM-Doyle May 29, 2017

Contributor

All of the loggers that you are examining use both, because all three apps call InitLoggingOptionsDBSystem() to initialize the connection to options db. However, the options db code is unnecessary.

The distinction allows UI concerns of option files and thresholds to be separate from the logger itself. It would allow a test suite to not require or use an options db file. We do not have such a test suite. It does allow code using the logger to not need to include (or transitively include) the options db header.

All three applications have a line InitLoggingOptionsDBSystem(); which finds all loggers initialized in static initialization and all loggers mentioned in OptionsDB and tries to configure them. You can remove that line in all 3 apps and all of the RegisterLoggerWithOptionsDB() lines in HumanClientApp The logger will work correctly, except it won't load the thresholds from the options db file.

Further more you can comment out the bodies of all of the functions in LoggerWithOptionsDB.cpp (return an empty set for LoggerOptionsLabelsAndLevels()). Everything will also work, except you won't be able to load/set thresholds in the options db file. Also the Logging tab in the options window will be blank. If you do this or remove LoggerWithOptionsDB from the build entirely, then you can isolate the problems to just the Logger code.

Are just the HumanClientFSM log messages going to the console, but not the ServerFSM messages?

Are all of the HumanClientFSM messages going to the console, or are some going to the log file?

If you change the FSM log level after the game is running does that change the problem or redirect the HumanClientFSM messages to file?

I went back through the travis logs and the OSX/Xcode linker warnings go back to January, when travis was first setup. The warnings are about a variety of boost systems including the logger, exceptions and date_time.

Are both the python regular and error messages going to stdout?

Do not waste too much time with the python loggers. I will rebase #669 and make the python logs work with the new logging system. I was waiting for you to work on the current errors. However, if you think it would help I can do that work sooner so that the python logger is the same as the other loggers.

Contributor

LGM-Doyle commented May 29, 2017

All of the loggers that you are examining use both, because all three apps call InitLoggingOptionsDBSystem() to initialize the connection to options db. However, the options db code is unnecessary.

The distinction allows UI concerns of option files and thresholds to be separate from the logger itself. It would allow a test suite to not require or use an options db file. We do not have such a test suite. It does allow code using the logger to not need to include (or transitively include) the options db header.

All three applications have a line InitLoggingOptionsDBSystem(); which finds all loggers initialized in static initialization and all loggers mentioned in OptionsDB and tries to configure them. You can remove that line in all 3 apps and all of the RegisterLoggerWithOptionsDB() lines in HumanClientApp The logger will work correctly, except it won't load the thresholds from the options db file.

Further more you can comment out the bodies of all of the functions in LoggerWithOptionsDB.cpp (return an empty set for LoggerOptionsLabelsAndLevels()). Everything will also work, except you won't be able to load/set thresholds in the options db file. Also the Logging tab in the options window will be blank. If you do this or remove LoggerWithOptionsDB from the build entirely, then you can isolate the problems to just the Logger code.

Are just the HumanClientFSM log messages going to the console, but not the ServerFSM messages?

Are all of the HumanClientFSM messages going to the console, or are some going to the log file?

If you change the FSM log level after the game is running does that change the problem or redirect the HumanClientFSM messages to file?

I went back through the travis logs and the OSX/Xcode linker warnings go back to January, when travis was first setup. The warnings are about a variety of boost systems including the logger, exceptions and date_time.

Are both the python regular and error messages going to stdout?

Do not waste too much time with the python loggers. I will rebase #669 and make the python logs work with the new logging system. I was waiting for you to work on the current errors. However, if you think it would help I can do that work sooner so that the python logger is the same as the other loggers.

@memem359

This comment has been minimized.

Show comment
Hide comment
@memem359

memem359 May 29, 2017

Contributor

If I do a grep for either "HumanClientFSM" or "ServerFSM", those type of messages are only going to stdout, none in the normal logs.

For the python output, I recognize the AI decision-making messages (what is in the production queue, priority for planet attacks, etc.). Those are going to stdout only.

I will try to figure out why TraceLogger(effects) is working (redirected to proper log file, correct human-readable FO class file and line number attached to message), while TraceLogger(FSM) is not working (only in stdout, hexcode for the class file, "[info]" for the log).

Edit: Did one turn with all logs on Trace threshold, switched to Debug for one turn, then back to Trace for one turn. Still no FSM-log messages in the regular logs, and only in stdout.

Contributor

memem359 commented May 29, 2017

If I do a grep for either "HumanClientFSM" or "ServerFSM", those type of messages are only going to stdout, none in the normal logs.

For the python output, I recognize the AI decision-making messages (what is in the production queue, priority for planet attacks, etc.). Those are going to stdout only.

I will try to figure out why TraceLogger(effects) is working (redirected to proper log file, correct human-readable FO class file and line number attached to message), while TraceLogger(FSM) is not working (only in stdout, hexcode for the class file, "[info]" for the log).

Edit: Did one turn with all logs on Trace threshold, switched to Debug for one turn, then back to Trace for one turn. Still no FSM-log messages in the regular logs, and only in stdout.

@memem359

This comment has been minimized.

Show comment
Hide comment
@memem359

memem359 May 29, 2017

Contributor

@LGM-Doyle Clues point to the problem being related to visibility=hidden.

I did a search for where DeclareThreadSafeLogger was used.
The "effects" log is in Effect.cpp and Universe.cpp. Those files, and the Logger code, are part of the Common target.
The "FSM" logs are in different targets. HumanClientFSM.cpp is part of the human client, and ServerFSM.cpp is part of the server (freeoriond) client.

As a test, I took a FSM log message that was in HumanClientFSM that was going to stdout, and also had it go to TraceLogger(effects). It still went to stdout.

I took an effects log message that was in Universe.cpp (and going to the correct log), and had it also going to TraceLogger(FSM). Those are showing up as FSM-log messages in the correct log output.

My guess is that the Logger is being treated as local to the Common library. Anything inside the Common target will work as expected; anything outside goes to stdout. I am going to try to use FO_COMMON_API in various places to see if that helps the "visibility", but that will take some time (and a lot of trial & error) to get straightened out. (All the preprocessor macros that are used for the Logger are making my brain hurt.)

Contributor

memem359 commented May 29, 2017

@LGM-Doyle Clues point to the problem being related to visibility=hidden.

I did a search for where DeclareThreadSafeLogger was used.
The "effects" log is in Effect.cpp and Universe.cpp. Those files, and the Logger code, are part of the Common target.
The "FSM" logs are in different targets. HumanClientFSM.cpp is part of the human client, and ServerFSM.cpp is part of the server (freeoriond) client.

As a test, I took a FSM log message that was in HumanClientFSM that was going to stdout, and also had it go to TraceLogger(effects). It still went to stdout.

I took an effects log message that was in Universe.cpp (and going to the correct log), and had it also going to TraceLogger(FSM). Those are showing up as FSM-log messages in the correct log output.

My guess is that the Logger is being treated as local to the Common library. Anything inside the Common target will work as expected; anything outside goes to stdout. I am going to try to use FO_COMMON_API in various places to see if that helps the "visibility", but that will take some time (and a lot of trial & error) to get straightened out. (All the preprocessor macros that are used for the Logger are making my brain hurt.)

@LGM-Doyle

This comment has been minimized.

Show comment
Hide comment
@LGM-Doyle

LGM-Doyle May 30, 2017

Contributor

@memem359 thanks for the additional information.

I've looked in the Xcode project file. I don't have access to OSX, I can't run Xcode and the format of the file is undocumented, so I may be misreading the file.

However, https://github.com/freeorion/freeorion/blob/master/Xcode/FreeOrion.xcodeproj/project.pbxproj#L2236 seems to indicate that freeorion common is statically linked to the boost framework. That would explain the problems.

The freeorioncommon dynamic library is statically linked to the boost log library and the other other modules dynamically link to freeorioncommon, and then link to a different instance of the boost log library. When the file sinks are configured freeorioncommon configures them in the only boost log library that it is linked to, but that is not the version that the other modules are using.

This may also explain the other linker warnings about visibility.

Could you try compiling the boost dependencies as dynamic libraries and removing the static linking from the Xcode project file?

Contributor

LGM-Doyle commented May 30, 2017

@memem359 thanks for the additional information.

I've looked in the Xcode project file. I don't have access to OSX, I can't run Xcode and the format of the file is undocumented, so I may be misreading the file.

However, https://github.com/freeorion/freeorion/blob/master/Xcode/FreeOrion.xcodeproj/project.pbxproj#L2236 seems to indicate that freeorion common is statically linked to the boost framework. That would explain the problems.

The freeorioncommon dynamic library is statically linked to the boost log library and the other other modules dynamically link to freeorioncommon, and then link to a different instance of the boost log library. When the file sinks are configured freeorioncommon configures them in the only boost log library that it is linked to, but that is not the version that the other modules are using.

This may also explain the other linker warnings about visibility.

Could you try compiling the boost dependencies as dynamic libraries and removing the static linking from the Xcode project file?

@memem359

This comment has been minimized.

Show comment
Hide comment
@memem359

memem359 May 30, 2017

Contributor

@LGM-Doyle I'll try shared libraries. Might take a while. (Want to test things carefully.)

I don't know the historical reason why it was done that way, for the Mac platform only, but if it can work with shared libraries only (instead of the mix, as you point out), that will simplify the FO build.

Contributor

memem359 commented May 30, 2017

@LGM-Doyle I'll try shared libraries. Might take a while. (Want to test things carefully.)

I don't know the historical reason why it was done that way, for the Mac platform only, but if it can work with shared libraries only (instead of the mix, as you point out), that will simplify the FO build.

@memem359

This comment has been minimized.

Show comment
Hide comment
@memem359

memem359 Jun 9, 2017

Contributor

@LGM-Doyle
For the Mac, moving the Boost libraries from static to shared seems to have fixed things.
Nothing is written to stdout or stderr (all messages being redirected to log output).
I can see the python output in the AI logs.

I need to check that I didn't break anything else while straightening this out, (and then get reasonable PRs ready,) but it looks like the resolution is in sight.

Contributor

memem359 commented Jun 9, 2017

@LGM-Doyle
For the Mac, moving the Boost libraries from static to shared seems to have fixed things.
Nothing is written to stdout or stderr (all messages being redirected to log output).
I can see the python output in the AI logs.

I need to check that I didn't break anything else while straightening this out, (and then get reasonable PRs ready,) but it looks like the resolution is in sight.

@LGM-Doyle

This comment has been minimized.

Show comment
Hide comment
@LGM-Doyle

LGM-Doyle Jun 9, 2017

Contributor

Once again thanks for working on this.

Do you know why or have a link explaining why the exception library needs to be compiled statically?

With the exception library compiled statically does the linker still give the warnings about weak symbols?

Even if those warning are not fixed. Don't hold up the parts that are fixed trying to fix the exceptions as well.

Contributor

LGM-Doyle commented Jun 9, 2017

Once again thanks for working on this.

Do you know why or have a link explaining why the exception library needs to be compiled statically?

With the exception library compiled statically does the linker still give the warnings about weak symbols?

Even if those warning are not fixed. Don't hold up the parts that are fixed trying to fix the exceptions as well.

@memem359

This comment has been minimized.

Show comment
Hide comment
@memem359

memem359 Jun 9, 2017

Contributor

The situation is this:
To get the attribute/visibility/default in front of the symbols that we want visible (and not hidden), Boost is requiring that the dynamic (shared) link macros be defined. There may be reasons to do that (maybe a Windows thing), but it was an obstacle to me for symbol visibility.

For the exception library, I don't know. The bjam/b2 script is very handy when building the standard version of the libraries, but it does make it hard to know what can be changed without breaking some other hidden (undocumented) assumption.

I ended up leaving visibility=default (no hidden symbols) for the SDK build and let the b2 script do the standard thing for Boost shared libraries. Too much work, otherwise.

However, that still means we need the right settings for the FO build, which is using the Boost includes to define the functions. That was the cause for the hundreds of warning messages: the Boost includes used by FO had hidden symbols, while the SDK libraries had default visibility.

For the FO build, I am now passing about a dozen Boost preprocessor macros. This will result in the symbols having the right visibility in those Boost includes. There are still a couple of dozen weak-symbol warnings (mostly from python), but the game seems to be working, so I'm not letting that hold me up. (If you really want or need more details, send me a PM on the forum.)

Contributor

memem359 commented Jun 9, 2017

The situation is this:
To get the attribute/visibility/default in front of the symbols that we want visible (and not hidden), Boost is requiring that the dynamic (shared) link macros be defined. There may be reasons to do that (maybe a Windows thing), but it was an obstacle to me for symbol visibility.

For the exception library, I don't know. The bjam/b2 script is very handy when building the standard version of the libraries, but it does make it hard to know what can be changed without breaking some other hidden (undocumented) assumption.

I ended up leaving visibility=default (no hidden symbols) for the SDK build and let the b2 script do the standard thing for Boost shared libraries. Too much work, otherwise.

However, that still means we need the right settings for the FO build, which is using the Boost includes to define the functions. That was the cause for the hundreds of warning messages: the Boost includes used by FO had hidden symbols, while the SDK libraries had default visibility.

For the FO build, I am now passing about a dozen Boost preprocessor macros. This will result in the symbols having the right visibility in those Boost includes. There are still a couple of dozen weak-symbol warnings (mostly from python), but the game seems to be working, so I'm not letting that hold me up. (If you really want or need more details, send me a PM on the forum.)

@LGM-Doyle

This comment has been minimized.

Show comment
Hide comment
@LGM-Doyle

LGM-Doyle Jun 10, 2017

Contributor

First don't let perfect get in the way of better. If you stop where you are now, the build is in better shape than when you started.

Second, since you are now a repository of information of the FreeOrion OSX SDK, the build system and boost, I was hoping you would post what you knew about boost exception so that the next dev could start from where you left off.

Third, problems with the exception linking probably won't appear until exceptions are being caught.

And last the documentation for non header only boost libraries says that a separately compiled binary for boost Exception is only required for certain versions of 32-bit Windows OS.

Have you tried removing the compiled portion of boost Exception from the OSX SDK?

Contributor

LGM-Doyle commented Jun 10, 2017

First don't let perfect get in the way of better. If you stop where you are now, the build is in better shape than when you started.

Second, since you are now a repository of information of the FreeOrion OSX SDK, the build system and boost, I was hoping you would post what you knew about boost exception so that the next dev could start from where you left off.

Third, problems with the exception linking probably won't appear until exceptions are being caught.

And last the documentation for non header only boost libraries says that a separately compiled binary for boost Exception is only required for certain versions of 32-bit Windows OS.

Have you tried removing the compiled portion of boost Exception from the OSX SDK?

@memem359

This comment has been minimized.

Show comment
Hide comment
@memem359

memem359 Jun 10, 2017

Contributor

Right now, nothing in the FO Xcode project file is explicitly linking to the Exception library.
So probably your 3rd point applies.

The SDK problems were when I was trying to build the SDK Boost libraries with visibility=hidden. I was confused about what b2 is (or is not) doing, and there were conflicts in the macros I was setting and the b2 build actions. That went away when I left it as visibility=default, so I no longer needed to monkey with the macros and I could let b2 do what it wants to do.

Some day I might try finding the minimal set of libraries and linking needed that will still let the SDK and FO work on the Mac. But probably not for some time.

Contributor

memem359 commented Jun 10, 2017

Right now, nothing in the FO Xcode project file is explicitly linking to the Exception library.
So probably your 3rd point applies.

The SDK problems were when I was trying to build the SDK Boost libraries with visibility=hidden. I was confused about what b2 is (or is not) doing, and there were conflicts in the macros I was setting and the b2 build actions. That went away when I left it as visibility=default, so I no longer needed to monkey with the macros and I could let b2 do what it wants to do.

Some day I might try finding the minimal set of libraries and linking needed that will still let the SDK and FO work on the Mac. But probably not for some time.

@LGM-Doyle

This comment has been minimized.

Show comment
Hide comment
@LGM-Doyle

LGM-Doyle Jun 10, 2017

Contributor

That's good.

Having the minimal number of included headers reduces compile time.
Having the minimal number of linked libraries reduces link time and start up time.

I don't think having the minimal number of libraries in the SDK is useful.

Having the minimal number of libraries in the SDK reduces the time to build the SDK, but that is a one time cost that most devs don't even pay.

Having the minimal number of libraries in the SDK provides the minimal development environment to OSX devs. It encourages reinventing the wheel if there is a useful library available but not in the SDK. Or just waiting for linux dev (who can access new libraries with minimal effort) to add features requiring experimenting with new libraries.

I don't know what the "right" set of libraries to include is. Including some standards track boost libraries that we are not yet using could be justified. Including libraries with more generic and better supported version of utilities where we have rolled our own is also arguable.

Contributor

LGM-Doyle commented Jun 10, 2017

That's good.

Having the minimal number of included headers reduces compile time.
Having the minimal number of linked libraries reduces link time and start up time.

I don't think having the minimal number of libraries in the SDK is useful.

Having the minimal number of libraries in the SDK reduces the time to build the SDK, but that is a one time cost that most devs don't even pay.

Having the minimal number of libraries in the SDK provides the minimal development environment to OSX devs. It encourages reinventing the wheel if there is a useful library available but not in the SDK. Or just waiting for linux dev (who can access new libraries with minimal effort) to add features requiring experimenting with new libraries.

I don't know what the "right" set of libraries to include is. Including some standards track boost libraries that we are not yet using could be justified. Including libraries with more generic and better supported version of utilities where we have rolled our own is also arguable.

@LGM-Doyle

This comment has been minimized.

Show comment
Hide comment
@LGM-Doyle

LGM-Doyle Jul 8, 2017

Contributor

@memem359 just checking to see how this work is progressing.

Contributor

LGM-Doyle commented Jul 8, 2017

@memem359 just checking to see how this work is progressing.

@memem359

This comment has been minimized.

Show comment
Hide comment
@memem359

memem359 Jul 8, 2017

Contributor

The PR for the SDK ( freeorion/freeorion-sdk#29 ) and the main code ( #1585 ) fix the Mac OSX / logger problems.
I don't have any other changes planned.
Waiting for someone to merge them or to request for other changes.

Contributor

memem359 commented Jul 8, 2017

The PR for the SDK ( freeorion/freeorion-sdk#29 ) and the main code ( #1585 ) fix the Mac OSX / logger problems.
I don't have any other changes planned.
Waiting for someone to merge them or to request for other changes.

@Vezzra

This comment has been minimized.

Show comment
Hide comment
@Vezzra

Vezzra Jul 9, 2017

Member

Yeah, sorry, still caught up in RL issues, so haven't found the time yet to get back to all the OSX/Xcode specific stuff. I have all those things on my list, but can't make any promises/predictions now - still struggling...

Member

Vezzra commented Jul 9, 2017

Yeah, sorry, still caught up in RL issues, so haven't found the time yet to get back to all the OSX/Xcode specific stuff. I have all those things on my list, but can't make any promises/predictions now - still struggling...

@LGM-Doyle

This comment has been minimized.

Show comment
Hide comment
@LGM-Doyle

LGM-Doyle Jul 9, 2017

Contributor

@Vezzra no need to apologize.

I wanted to check that these improvements are not forgotten.

Good luck with RL.

Contributor

LGM-Doyle commented Jul 9, 2017

@Vezzra no need to apologize.

I wanted to check that these improvements are not forgotten.

Good luck with RL.

@memem359

This comment has been minimized.

Show comment
Hide comment
@memem359

memem359 Aug 11, 2017

Contributor

Bump?
(Not urgent, but it would be convenient to have the Logger working again on the Mac.)

Contributor

memem359 commented Aug 11, 2017

Bump?
(Not urgent, but it would be convenient to have the Logger working again on the Mac.)

MatGB added a commit to MatGB/freeorion that referenced this issue Aug 15, 2017

Make default logging threshold for Release be debug.
As discussed in issue freeorion#1575, there are currently not enough logs at the
info, warning and error level for the log files to be useful to testers.
Since we do not have separate targets for players, testers and devs,
this commit is setting all build types default logger thresholds to
debug.
@Dilvish-fo

This comment has been minimized.

Show comment
Hide comment
@Dilvish-fo

Dilvish-fo Sep 2, 2017

Member

@dbenage-cx and @memem359 given that Vezzra is probably still rather swamped, and we want most of his next attention to go towards the 0.4.7.1 bugfix, could both of you please help move resolution along by summarizing your take on the status of the respective referenced PRs that are hoped to fix this, (commenting in those PRs, not here) both with regards to how they work for you and whether or not it seems to you that all comments have been addressed?

Member

Dilvish-fo commented Sep 2, 2017

@dbenage-cx and @memem359 given that Vezzra is probably still rather swamped, and we want most of his next attention to go towards the 0.4.7.1 bugfix, could both of you please help move resolution along by summarizing your take on the status of the respective referenced PRs that are hoped to fix this, (commenting in those PRs, not here) both with regards to how they work for you and whether or not it seems to you that all comments have been addressed?

adrianbroher added a commit to freeorion/freeorion-sdk that referenced this issue Nov 5, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment