Difference between revisions of "Conditional Compiler Options"

From Lazarus wiki
Jump to navigationJump to search
 
(33 intermediate revisions by 6 users not shown)
Line 1: Line 1:
−
This page collects ideas of how to implement conditional compiler options in lazarus.
+
{{Conditional_Compiler_Options}}
  
−
First it should be collected the cases, where conditional compiler options are needed.
+
==Overview==
 +
Since Lazarus 0.9.29 you can define build modes and conditional compiler options. These options depend on current target OS, CPU, widgetset and project's build mode.
  
−
=Case studies=
+
For conditionals see here [[Macros and Conditionals]].
  
−
==Conditional Package Requirement: VirtualTreeView / multilog==
+
You can set the build macros for a package via [[IDE_Window: Compiler Options#Build_Macros|package editor / Compiler Options / Build Macros]].
  
−
Make possibly to define a package requirement as optional (Should be
+
You can set the build macros for a project via [[IDE Window: Compiler Options#Build_Macros|Project / Project Options / Compiler Options / Build Macros]].
−
available both to package and program).
 
−
Concrete situation: VirtualTreeView requires multilog package to help
 
−
debug code. In a release is not desired to have such dependency.
 
−
Currently in the release is necessary to remove the dependency from the  
 
−
package, and then add again to reenable debugging.
 
−
An idea is to have groups of conditional requirements. Each group would
 
−
have  a define value associated to be used at compile time (e.g:  
 
−
'DEBUG_CODE') and child packages. Each group would have a enabled flag.
 
−
If enabled flag is set, the child packages are added as requirements and
 
−
the define value used at compile time.
 
  
−
*Other packages will use the same Debug/Release differences. In big projects normally only a small part should be set verbose (into debugging mode).
+
==Target specific units - Doable via FPC directives, no Lazarus extras needed==
 +
Concrete situation: LCL extensions package has a unit (OleUtils) that implements TOLEStream. It only makes sense in Windows. Currently the unit is added in all widgetsets but all code is wrapped around a ifdef Windows define so is seen as a dummy unit in other widgetsets.
  
 +
Notes:
 +
*All units should be added to the package, independent if they are used. If a unit should not always be compiled (not added to the uses section of the package), just unset the 'uses unit' checkbox and add for example {$IFDEF win32}uses oleutils{$ENDIF} to a package unit.
 +
*You can put units and include files specific to targets into sub directories as demonstrated in the Lazarus and FPC sources (units/$(TargetOS)).
 +
*Since 0.9.31 multiple files with the same name can be added to packages.
  
−
==Target specific units==
+
+=What will not be implemented==
 +
*A global Debug/Verbose buildmode. Almost no one wants to increase verbosity of all packages, nor debug all packages. But you can define one for your own packages.
 +
*Conditional units. This is already flexible doable via FPC directives and IDE macros.
  
−
Make units packages/projects optional according to widgetset.
+
==Future development / Wishes==
−
Concrete situation: LCL extensions package has a unit (OleUtils) that
+
*Use a package only under one target, e.g. only under Windows and OS X, but not under Linux or BSD.
−
implements TOLEStream. It only makes sense in win32. Currently the unit
 
−
is added in all widgetsets but all code is wrapped around a ifdef
 
−
Windows define so is seen as a dummy unit in other widgetsets.
 
  
−
Notes:  
+
{{Template:Directives, Defines and Conditionals}}
−
*All units should be added to the package, independent if they are used. If they not always used, you can already check the flag.
+
[[Category:Conditionals]]
−
**If the "uses unit" flag is not set, the unit will not be compiled in none cases. Nor in win32 (where is needed) neither in the other systems. It will be compiled only if another unit in the package uses it. That's not the case.
 
−
*The above example is about windows. That has nothing to do with the widgetset. The qt and gtk2 widgetsets are also running under windows.
 
−
*You can put units specific to targets into sub directories as demonstrated in the Lazarus and FPC sources.
 
−
**It does not work for the cited example. I created a units\win32, put OleUtils.pas inside and set "units\$(TargetOS)\" in Other Units path (Compiler Options) but the unit is not compiled even in win32.
 
−
*There is no real need for conditional options for units.
 

Latest revision as of 16:27, 25 March 2017

│ English (en) │ français (fr) │

Overview

Since Lazarus 0.9.29 you can define build modes and conditional compiler options. These options depend on current target OS, CPU, widgetset and project's build mode.

For conditionals see here Macros and Conditionals.

You can set the build macros for a package via package editor / Compiler Options / Build Macros.

You can set the build macros for a project via Project / Project Options / Compiler Options / Build Macros.

Target specific units - Doable via FPC directives, no Lazarus extras needed

Concrete situation: LCL extensions package has a unit (OleUtils) that implements TOLEStream. It only makes sense in Windows. Currently the unit is added in all widgetsets but all code is wrapped around a ifdef Windows define so is seen as a dummy unit in other widgetsets.

Notes:

  • All units should be added to the package, independent if they are used. If a unit should not always be compiled (not added to the uses section of the package), just unset the 'uses unit' checkbox and add for example {$IFDEF win32}uses oleutils{$ENDIF} to a package unit.
  • You can put units and include files specific to targets into sub directories as demonstrated in the Lazarus and FPC sources (units/$(TargetOS)).
  • Since 0.9.31 multiple files with the same name can be added to packages.

+=What will not be implemented==

  • A global Debug/Verbose buildmode. Almost no one wants to increase verbosity of all packages, nor debug all packages. But you can define one for your own packages.
  • Conditional units. This is already flexible doable via FPC directives and IDE macros.

Future development / Wishes

  • Use a package only under one target, e.g. only under Windows and OS X, but not under Linux or BSD.
Directives, definitions and conditionals definitions
global compiler directives • local compiler directives

Conditional Compiler Options • Conditional compilation • Macros and Conditionals • Platform defines
$IF


Retrieved from "http://wiki.freepascal.org/index.php?title=Conditional_Compiler_Options&oldid=108439"