Difference between revisions of "SG LOG"

From FlightGear wiki
Jump to: navigation, search
Line 5: Line 5:
 
Logging settings can be modified using the <code>--log-level=[level]</code> [[command line]] option, detailed help about most available command line options can be obtained from the fgfs executable by calling it with the following arguments: <code>--help --verbose</code>.
 
Logging settings can be modified using the <code>--log-level=[level]</code> [[command line]] option, detailed help about most available command line options can be obtained from the fgfs executable by calling it with the following arguments: <code>--help --verbose</code>.
  
<code>
+
<pre>
 
  --log-level={bulk,debug,info,warn,alert}
 
  --log-level={bulk,debug,info,warn,alert}
 
                                 Specify which logging level to use
 
                                 Specify which logging level to use
Line 12: Line 12:
 
                                 Specify which logging class(es) to use
 
                                 Specify which logging class(es) to use
  
</code>
+
</pre>
  
 
If you are interested in simply logging certain properties to a file at runtime, you can use either FlightGear's built-in logging framework, or the [[generic protocol]].  See [[Logging properties]] and [[Generic protocol]] for more details.
 
If you are interested in simply logging certain properties to a file at runtime, you can use either FlightGear's built-in logging framework, or the [[generic protocol]].  See [[Logging properties]] and [[Generic protocol]] for more details.

Revision as of 15:59, 28 January 2016

Merge-arrows.gif
It has been suggested that this article or section be merged with SG_LOG().

SG_LOG is a wrapper macro for the SimGear logstream class. By default, the logstream class writes all output to the console. SG_LOG simplifies debugging for core developers who regularly compile from source. It allows you to easily associate your debug messages with a "channel" and with a "priority". This mechanism allows users to explicitly enable to certain log messages, while ignoring others. This can be helpful in order to troubleshoot certain problems.

Logging settings can be modified using the --log-level=[level] command line option, detailed help about most available command line options can be obtained from the fgfs executable by calling it with the following arguments: --help --verbose.

 --log-level={bulk,debug,info,warn,alert}
                                Specify which logging level to use

 --log-class=[ai,environment,flight,general,io,network,sound,terrain,...]
                                Specify which logging class(es) to use

If you are interested in simply logging certain properties to a file at runtime, you can use either FlightGear's built-in logging framework, or the generic protocol. See Logging properties and Generic protocol for more details.

Cquote1.png The standard mechanism for making FlightGear "log" stuff to the console (or log file) is using the SG_LOG() macro
— Hooray (Thu Feb 26). Re: 3.4 and the pain begins ....
(powered by Instant-Cquotes)
Cquote2.png

Development

Cquote1.png 'm working a bit on reworking the logging exposed to Nasal, since it hasn't been updated in years (besides the addition of the never-used logprint() by James, the old printlog() only goes to the $FG_HOME/fgfs.log file if it would also go to the console and is implemented in globals.nas - aka can't be depended on in $FG_ROOT/Nasal/*.nas). This is going to eventually help with the Nasal REPL (aka to capture output), but I discovered something really weird: sglog().would_log() returns true for any priority >= INFO! This almost seems like a bug to me, but OTOH it is required by the SG_LOG() macro to ensure that the logging file is not ignored in the if statement (since SG_LOG() uses would_log()).
— Philosopher (Fri Mar 07). sglog().would_log().
(powered by Instant-Cquotes)
Cquote2.png

Related content

Wiki articles

Source files