# -*- mode: shell-script -*-
#
# FPC configuration file for Castle Game Engine.
# Pretty much normal configuration for people that like modern ObjectPascal
# and ObjFpc mode.
#
# Accepts two switches: DEBUG and RELEASE. If you don't define any of them
# debug and optimizing code will be done according to compiler defaults.
# Never define both of them.
#
# Accepts a switch CASTLE_ENGINE_PATHS_ALREADY_DEFINED:
# in this case we will assume that proper -Fu and -Fi, to provide
# paths for FPC to our units, have already been defined.
# This allows to call FPC from any directory (otherwise you have to call
# FPC from this directory, containing castle-fpc.cfg, to make relative paths
# here work).
#
# For alternative, more flexible compilation method use tools/castle-engine.lpr .
#
# ----------------------------------------------------------------------

# Show FPC logo (shows fpc version)
-l

# Show warnings + notes.
# Do not show hints (there are too many useless hints produced by FPC).
-vwn

# Input/output checks : yes, always, even in release version -- my code
# depends on the fact that io errors in std Pascal funcs are checked
# automatically (and raise exceptions if SysUtils is compiled in)
-Ci

# syntax options --------------------------------------------------------

# Default syntax mode.
#
# We use objfpc mode for everything. Some reasons why it's better
# than delphi mode:
# - There are some things strange in delphi mode, for compat with delphi/tp,
#   that sometimes bite me (like the fact that in FPC >= 2.0.3
#   Single(Integer) makes a variable typecast, not a value typecast).
# - Moreover, ObjFpc has many sensible improvements:
#   the whole way of assigning procedural variables
#   is much better ("@" is required, and assignment is always checked
#   for parameter correctness (in delphi mode @ may be omitted; when it's
#   not omitted, you can cheat and pass procedure with not matching params))
# - Check that method parameter names must differ from class
#   fields/methods/properties --- this is great.
-Mobjfpc

# macros on
-Sm
# c-like operators +=, -= etc.
-Sc
# allow LABEL and GOTO
-Sg
# inline allowed
-Si
# use ansistrings
-Sh

# units/includes paths --------------------------------------------------

# It seems that FPC does not define symbol UNIX before reading config file,
# even though it defines LINUX (or FREEBSD; I assume that this is also
# the case with DARWIN).
# But I need symbol UNIX *now* to include paths common for all UNIXes.
#IFDEF LINUX
  #DEFINE UNIX
#ENDIF
#IFDEF DARWIN
  #DEFINE UNIX
#ENDIF
#IFDEF FREEBSD
  #DEFINE UNIX
#ENDIF

# Looks like MSWINDOWS symbol needs to be fixed now, just like UNIX above.
#IFDEF WIN32
  #DEFINE MSWINDOWS
#ENDIF
#IFDEF WIN64
  #DEFINE MSWINDOWS
#ENDIF

#IFNDEF CASTLE_ENGINE_PATHS_ALREADY_DEFINED

  # Common paths for all OSes
  -Fusrc/base/
  -Fisrc/base/
  -Fusrc/fonts/
  -Fisrc/fonts/
  -Fusrc/opengl/
  -Fisrc/opengl/
  -Fisrc/opengl/glsl/
  -Fusrc/window/
  -Fisrc/window/
  -Fisrc/window/gtk/
  -Fusrc/images/
  -Fisrc/images/
  -Fusrc/3d/
  -Fisrc/3d/
  -Fusrc/3d/opengl/
  -Fisrc/3d/opengl/
  -Fusrc/x3d/
  -Fisrc/x3d/
  -Fisrc/x3d/teapot_data/
  -Fusrc/x3d/opengl/
  -Fisrc/x3d/opengl/
  -Fisrc/x3d/opengl/glsl/
  -Fusrc/audio/
  -Fisrc/audio/
  -Fusrc/net/
  -Fisrc/net/
  -Fusrc/castlescript/
  -Fisrc/castlescript/
  -Fusrc/ui/
  -Fisrc/ui/
  -Fusrc/ui/opengl/
  -Fisrc/ui/opengl/
  -Fusrc/game/
  -Fisrc/game/

  #IFDEF UNIX
    -Fusrc/base/unix/
    -Fisrc/base/unix/
    -Fusrc/opengl/unix/
    -Fisrc/opengl/unix/
    -Fusrc/window/unix/
    -Fisrc/window/unix/
  #ENDIF

  #IFDEF MSWINDOWS
    -Fusrc/base/windows/
    -Fisrc/base/windows/
    -Fusrc/fonts/windows/
    -Fusrc/opengl/windows/
    -Fisrc/opengl/windows/
    -Fusrc/window/windows/
    -Fisrc/window/windows/
    -Fusrc/ui/windows/
    -Fisrc/ui/windows/
  #ENDIF

  #IFDEF ANDROID
  -Fusrc/base/android/
  -Fisrc/base/android/
  #ENDIF

#ENDIF

# debug specific -------------------------------------------------

#IFDEF DEBUG
  #WRITE Compiling Debug Version

  # range checks
  -Cr
  # overflow checks
  -Co

  # Stack overflow checks.
  #
  # castle fails with stack checking errors on x86-64.
  # Otherwise, works OK, so I guess it's FPC bug.
  # TODO: make testcase and submit. For now, stack checking is not
  # done on x86-64.
  #
  # It also causes failures on Android with pthread in castleandroidnativeappglue.pas.
  #IFNDEF CPUX86_64
  #IFNDEF ANDROID
  -Ct
  #ENDIF
  #ENDIF

  # assertions checks
  -Sa

  # virtual method table checks
  -CR

  # debug info for gdb and browser.
  -g
  #-bl

  # LineMode unit for backtraces with line info.
  -gl

  # HeapTrc unit to track memory leaks.
  #
  # -gh is not enabled by default, because
  # it produces confusing output when the program exits with
  # exception (like from ProgramBreak) or Halt: it will always show
  # some leaked memory in this case. Indeed, FPC always leaks memory then,
  # this is FPC problem (although harmless, since in this case OS
  # will free this memory anyway).
  #
  # If you understand this, you can (and should) enable -gh and use
  # it to catch memory leaks in your programs.
  # There should be *no* memory leaks from Castle Game Engine
  # when the program exits in a usual fashion.
  #-gh

  # Check pointer validity.
  #
  # -gc is not used by default, because
  #
  # 1.It makes many false errors (when I dereference memory allocated
  #   by other libraries, e.g. libpng or gtk). I'm masking them by
  #
  #     { We dereference here memory allocated with PNG, so pointer checks
  #       will make false errors. }
  #     {$checkpointer off}
  #
  #     ....
  #
  #     {$ifdef KAMBI_CHECK_POINTER}
  #     { Turn checkpointer back on }
  #     {$checkpointer on}
  #     {$endif}
  #
  #   (I need -dKAMBI_CHECK_POINTER for this trick, since {$ifopt checkpointer}
  #   doesn't work.)
  #   But this masking is error prone, so a lot of valid code may still report
  #   false errors. IOW, unless you know what you're doing (and can
  #   recognize false error from a real one in the engine code), don't use -gc.
  #
  # 2.Also, -gc for whole code still makes code much slower.
  #
  # Note that -gc requires -gh because checking pointer
  # validity is part of HeapTrc unit.
  #-gc
  #-dKAMBI_CHECK_POINTER
#ENDIF

# profiling ------------------------------------------------------------------
#
# Profiling options should be used without -dDEBUG,
# -dDEBUG code may be (slightly) slower in (slightly)
# different places because of debug checks (range, overflow, stack checks etc.).
#
# They generally should be used with -dRELEASE, as you want to profile
# program timings experienced by the user, although sometimes -dRELASE may cause
# optimizations that may obfuscate profiler output.
# So sometimes yoy may want to undefine both DEBUG and RELEASE.

# gprof
# -pg

# valgrind
#-gl
#-gv

# release specific -----------------------------------------------

#IFDEF RELEASE
  #WRITE Compiling Release Version

  # optimize : level 2, faster code
  -O2
  #-OG # obsolete, FPC optimizes for faster code always

  # (Don't optimize for Pentium;
  #  1. there are still some people with older i386 processors ?
  #  2. these Pentium-specific optimizations don't seem to give *any*
  #     real improvement for my code (checked with rayhunter
  #     with FPC 1.0.10;  TODO -- do some speed checks with FPC 2.0.0))
  # Note: remember, if you enable it, wrap it in #IFDEF CPUI386
  # -Op2

  # (smartlink turned off because REALLY slows down compilation
  # and doesn't reduce size of my programs too much)
  #-CX
  #-XX

  # strip symbols from exe (symbols are used only in debugging)
  -Xs
#ENDIF

# eof --------------------------------------------------------------------------
