Having ported a large real-time graphical application from Virtual Pascal (DPMI) to Free Pascal Linux , there is one aspect I haven't managed to overcome.

For a number of reasons Lazarus was not used , and Geany is used as the IDE , which works well.

Unlike Virtual Pascal which allowed me to put different code in separate directories , Free Pascal seems to want ALL unit files in one huge directory which makes it difficult to keep proper revision control.

For example if I decide to use fpGUI , I would like to put all the fpGUI source code into one directory and the actual application (my code) in a separate directory.

Any suggestions ?

Thanks in advance
Brian

Where did you get this idea from ?

You can perfectly do this, all my code is scattered over multiple directories. All you need to do is add -Fu options.

Michael.

some days before we had same type of thread ...

the "problem" is

-Fu is not recursive!

Michael Van Canneyt wrote

On Tue, 30 Sep 2014, Brian wrote: > Having ported a

large real-time graphical application from Virtual Pascal (DPMI) to Free Pascal Linux , there is one aspect I haven't managed to overcome. For a number of reasons Lazarus was not used , and Geany is used as the IDE , which works well. Unlike Virtual Pascal which allowed me to put different code in separate directories , Free Pascal seems to want ALL unit files in one huge directory which makes it difficult to keep proper revision control.

Where did you get this idea from ? > For

example if I decide to use fpGUI , I would like to put all the fpGUI source code into one directory and the actual application (my code) in a separate directory. Any suggestions ?

You can perfectly do this,

all my code is scattered over multiple directories.

All you need to do

is add -Fu options.

Michael.

And luckily not. The result would be a disaster !

However, you can use wildcards:
-Fu/home/some/dir/*

Michael.

We're programmers. Creating our own tools for mundane work is not a "problem" :-)

A few year back at my old company, for Delphi work we developed a small helper app. We gave it a root folder, it gave us back a string containing all sub-folders in a format suitable for pasting into required Library Paths (going via a intermediate listbox so we could exclude any subfolders we didn't want - we had folders for docs for instance). Only needed this app when configuring a new install of Delphi.

Shouldn't take you long to generate a similar app for automating a string for -Fu. :-)

Mike (one of the other ones)

That's not what Brian asked for. He asked whether he can use multiple directories, not whether he can use them recursively. And the former is definitely the case.

Regards,
Sven

Michael Thompson wrote

Shouldn't take you long to generate a similar app for automating a string for -Fu. :-)

+1

:-D

Regards,
- Graeme -

Brian wrote

For example if I decide to use fpGUI , I would like to put all the fpGUI source code into one directory

fpGUI is scattered over multiple directories too, so no idea why you thought all units must be in a single directory.

In the <fpgui>/src/ directory is a "extrafpc.cfg" file that defines multiple source directory locations. Those include "unit" directory and "include" directory locations. All the demos include with fpGUI does a similar thing.

Regards,
- Graeme -

That's not what Brian asked for. He asked whether he can use multiple directories, not whether he can use them recursively. And the former is definitely the case.

And indeed it's a disaster, because you might to restructure your units directory if it works recursively depending on how you layout it. Example: If under the same directory you have units for all targets you want to support, it's a hell after -Fu works recursively.

as for other points (for example "with" use/misuse) ... for me -Fu recursive, "with" statement and others may be usefull tools ... not for you!

there no absolute answer!

may be other people don't do the same
kind of job I do, or you do. may they they don't work the same way I do, or you do!

abraço!

Philippe

leledumbo wrote

> That's not what Brian asked for. He asked whether he can

use multiple directories, not whether he can use them recursively. And the former is definitely the case.

And indeed it's a disaster,

because you might to restructure your units

directory if it works

recursively depending on how you layout it. Example:

If under the same

directory you have units for all targets you want to

support, it's a

hell after -Fu works recursively.

-- View this message in

context:
http://free-pascal-general.1045716.n5.nabble.com/Free-Pascal-Directories-tp5720212p5720226.html [1]

Sent from the Free Pascal - General mailing list archive at

Nabble.com.

_______________________________________________

fpc-pascal maillist -

http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal [2]

Links:
------
[1]
http://free-pascal-general.1045716.n5.nabble.com/Free-Pascal-Directories-tp5720212p5720226.html [2]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Sorry , I wasn't specific about my problem. Using the example in the fpGUI distribution (but the following comments are not specific to fpGUI).

I want to use Geany as the IDE without using .CFG files and compiling from the commandline.

If UNITPATH is set in the main program (the fpGUI is a good example) , it will fail to find fpg_base
helloworld.pas(27,3) Fatal: Can't find unit fpg_base used by HelloWorld

program HelloWorld;
{$mode objfpc}{$H+}
{$UNITPATH .../fpgui/fpgui-1.2/src/units/i386-linux}

if the absolute directory location is specified in the UNITPATH directive , the complier will find fpg_base but then fail to find the next unit called by fpg_base ...

Fatal: Can't find unit fpg_impl used by fpg_base

What am I missing?

Thanks in Advance
Brian

You can give this directive multiple times to add all needed paths. Or you can pass the unit paths via -Fu in Geany.

Mattias

Mattias Gaertner wrote

[...] > Do you have an example of how you can pass the unit paths via -Fu in Geany > ?

If you don't know how to do this in Geany, maybe it is not a good editor choice for you.

You use the command line from the terminal:
fpc -Fufpgui/fpgui-1.2/src/units/i386-linux -Fu... yourprogram.pas And put it into the build commands.

Mattias

Mattias Gaertner wrote

fpc -Fufpgui/fpgui-1.2/src/units/i386-linux -Fu... yourprogram.pas And put it into the build commands.

And just to clarify for Brian.... the *.cfg file is simply a text file containing one FPC command line parameter per line. You then only need to reference two command line parameters when compiling your program, instead of a complex loooong command.

Example usage:
fpc @extrafpc.cfg yourprogram.pas

Regards,
- Graeme -

Thanks for all the commandline suggestions , but my question is about using Geany as the IDE , not running the compiler from the commandline. BTW : I only use fpGUI as an example to illustrate the issue.

Using Geany as the IDE :
The FPC documentation is not correct :
1.3.38 $UNITPATH : Specify unit path.
http://www.freepascal.org/docs-html/prog/progsu121.html#x129-1300001.3.38

If the directive is added (below) to the main program FPC will fail to find the unit directory i386-linux.
{$UNITPATH .../fpgui/fpgui-1.2/src/units/i386-linux}

To make it work you must include the absolute directory path such as : {$UNITPATH /home/mydir/fpgui/fpgui-1.2/src/units/i386-linux} and then it only finds the first unit in the uses list and cannot find the rest of the units in i386-linux.

Why doesn't FPC continue to look for units in the directory specified by $UNITPATH ?

Regards
Brian

Brian wrote

Thanks for all the commandline suggestions , but my question is about using Geany as the IDE , not running the compiler from the commandline.

Geany itself will call the compiler via the command line, so it presumably has ways to specify additional command line options.

If the directive is added (below) to the main program FPC will fail to find the unit directory i386-linux. {$UNITPATH .../fpgui/fpgui-1.2/src/units/i386-linux}

Note that "..." is not a valid directory specifier. Also note that if you use a relative path, it should be relative to the location of the source file (and not relative to e.g. the top level directory of your project).

Tell Geany to pass the command line option -vtu to the compiler. The compiler will then print out which directories it searches for which unit files.

Jonas

Jonas , thanks very much as I now see what is happening.

FPC only searches the specific directory and not any lower level directories. In this case the unit called is in a lower level directory.

Is there any way using Geany to add $UNITPATH directives in the main program or path info in Geany so FPC is able to find the required units?

Thanks
Brian

your best bet it to use a wildcard:

-Fu/path/to/my/dir/*

or, presumably:

{$UNITPATH /path/to/my/dir/* }

this will only search 1 level below 'dir', but maybe this is enough for your situation ?

Michael.

Thanks Michael.

Jonas tip allows me to see what is happening when using Geany. In the case of fpGUI , the fpmake creates all the .ppu and .o files and places them in directory ../i386-linux.

Using either the wildcard * or absolute name of the directory is ok . The compiler finds (in this example) fpg_base but then wants to get the next unit (fpg_impl) called in fpg_base , but seems to expect the .pas file rather than just using the .ppu and .o files that have already been compiled.

It is as if the compiler is trying to build rather than just linking the existing compiled .ppu and .o files.

Searching file /usr/lib/fpc/2.6.4/fpg_impl.pas... not found Fatal: Can't find unit fpg_impl used by fpg_base

Is there any way to tell the compiler to just link existing .ppu and .o files ?

Thanks
Brian

In our previous episode, Brian said:

Is there any way to tell the compiler to just link existing .ppu and .o files ?

There are three things in such case:

- compile the immutable packages with -Ur
- find actually WHY the compiler doesn't want to use the .ppu's and get to the root of the problem. Use -va to prints LOTS of debugging info.
- make sure that the compiler can't find any source.

Marco ,

The fpGUI units were recompiled with directive -Ur

When the helloworld.pas file is compiled using Geany (with -Ur and -Va) for some reason FPC can't find the unit (fpg_impl.ppu) called by fp_base , even though it is present in the folder with fpb_base.

[0.058] Load from FPG_BASE (interface) unit FPG_IMPL [0.058] Loading unit FPG_IMPL
[0.058] Unitsearch: fpg_impl.ppu
[0.058] Searching file fpg_impl.ppu... not found

... FPC then begins searching for the source file fpg_impl.pas which is not in the directory and eventually fails.

Any suggestions ?

Thanks
Brian

In our previous episode, Brian said:

If the .ppu was rejected, it would say that /here/ some line with "recompiling" in it.

So, then somehow the directory with the .ppu is not passed to the compiler or rejected by it. That means going back one step (to Jonas' answer) and check that the -Fu with the .ppu directory is accepted.

The compiler accepts the directory and loads the first unit fpg_base , but then fails to load the next unit that is called by fpg_base which is fpg_impl . Then it fails.

Regards
Brian

Can I use {$unitpaht /home/some/dir/*} ?

My mistake ...

Using directive -Va I can see that PFC cannot find fpg_base also.

Question : Does the directive $UNITPATH acvtually work ?

Regards
Brian

bad ideia :

(with windows we have a limite from the command line size!)

I copy recursively all the files from directories I need in a unique directory ... then compile from it!!!

ugly! ... may be ... but
it works !!! recursively!!! and it is quite fast to copy ... and I spent time in other things!!!

Brian wrote

Jonas

, thanks very much as I now see what is happening.

FPC only

searches the specific directory and not any lower level

directories.

In this case the unit called is in a lower level directory.

Is

there any way using Geany to add $UNITPATH directives in the main program

or path info in Geany so FPC is able to find the required

units?

http://free-pascal-general.1045716.n5.nabble.com/Free-Pascal-Directories-tp5720212p5720252.html [1]

Sent from the Free Pascal - General mailing list archive at

Nabble.com.

_______________________________________________

fpc-pascal maillist -

http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal [2]

Links:
------
[1]
http://free-pascal-general.1045716.n5.nabble.com/Free-Pascal-Directories-tp5720212p5720252.html [2]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Conclusion :

Using {$UNITPATH /home/some/*} in the main program DOES NOT WORK !

When using Geany if the directive is added in Set Build Command , COMPILE line as -Fu/home/some/* it works properly.

Much better than dumping everything into one pot.

Regards
Brian

Brian wrote

Conclusion : Using {$UNITPATH /home/some/*} in the main program DOES NOT WORK !

[...]

=(

Brian wrote

Conclusion : Using {$UNITPATH/home/some/*} in the main program DOES NOT WORK !

It behaves exactly as documented at
http://www.freepascal.org/docs-html/prog/progsu121.html :

"Note that this switch does not propagate to other units, i.e. it’s scope is limited to the current unit."

"unit" should be interpreted as "compilation unit" in this context.

Jonas

Correct. But it does not work fine if the path contains two or more units. E.g:

{$unitpath path\to\the\all\units\of\the\synapse40\source\lib}
"..\..\3rdparty\synapse40\source\lib\httpsend.pas(72,3) Fatal: Can't find
unit blcksock used by httpsend."

I tried too {$unitpath path\to\the\all\units\of\the\synapse40\source\lib\*}:

"Can not find unit httpsend used by myunit."

=(

That's because httpsend is a different unit than the one that included the {$unitpath ...} directive. Once you are inside the httpsend unit, the directive is no longer valid, as the documentation explains. And hence, other units in that same directory won't be found.

I understand that this may be counter-intuitive, but it's how the feature was designed and how it is documented. I think the directive is completely local to a single compilation unit because, presumably, it was originally intended to allow for having units in "packages" to contain their own unitpath directives without polluting the unit search path of the main program.

I tried too {$unitpath path\to\the\all\units\of\the\synapse40\source\lib\*}: "Can not find unit httpsend used by myunit."

Of course that won't work: it will add all directories under "...\synapse40\source\lib" to the unit search path, but not "...\synapse40\source\lib" itself (which is where your httpsend unit is located).

Jonas

Hm... now it is clear to me. Thanks!

But it would be an nice feature in Free Pascal, something like the "import" of Python and Java. =)

[...] But it would be an nice feature in Free Pascal, something like the "import" of Python and Java. =)

Java requires a CLASSPATH for the imports to work, does it not?

Mattias

You can import one or more classes. E.g, you can use it:

import com.example.Foo;
import com.example.Bar;

or:

import com.example.*;

In first example, you import only Foo and Bar classes, in second you import any classes in "example", Foo, Bar, Other.

"Philippe" wrote

bad ideia : (with windows we have a limite from the command line size!)

If you can't work with 8000 characters then simply use a cfg file and pass that. It's not as if you change your paths every hour...

Regards,
Sven

@cfg

I read about that option in a previous message of the thread ... clearly a better ideia!!! ... I´ll use it for sure!

taking
advantage of the oportunity. when one type fpc in the command line, he/she gets:

D:psl9c9>fpc
Free Pascal Compiler version 2.6.4
[2014/03/06] for i386
Copyright (c) 1993-2014 by Florian Klaempfl and
others
c:FPC2.6.4bini386-Win32ppc386.exe [options] <inputfile> [options]

and so one ...

and if I did not missed it, there is nothing about @cfg !

that is the reason while I never used it!

Sven Barth wrote

Am 02.10.2014 22:25 schrieb "Philippe"

:

> > bad ideia : > > (with windows we

have a limite from the command line size!)

If you can't work with

8000 characters then simply use a cfg file and pass that. It's not as if you change your paths every hour...

In our previous episode, silvioprog said:

I think Mattias meant that Java still needs to pass paths outside the source. So the hierarchical system of Java only fixes recursion, not all paths.

And it adds the limitation that if you move a class from one namespace to the other, you need to adapt all applications. In that, the concept is very rigid compared to FPC units directories.

Brian wrote

Is there any way to tell the compiler to just link existing .ppu and .o files ?

Yes. In the case of fpGUI (as as an example), the <fpgui>/src/build.bat or build.sh builds the fpGUI framework and places the compiled units in a library output directory <fpgui>/lib/<fpctarget>

The examples/demos of fpGUI doesn't recompile the fpGUI framework, it simply uses the *.ppu and *.o files located in the 'lib/<target>/' directory. See the extrafpc.cfg files in the demo directories.

Here is a snippet:

-FUunits
-Fu../../../lib/$fpctarget

Not the -Fu doesn't reference the <fpgui>/src/ directory, but rather the lib directory.

Regards,
- Graeme -

Brian wrote

When the helloworld.pas file is compiled using Geany

Take a look at the <fpgui>/docs/INSTALL.txt file. There I explain how to setup and use fpGUI with various IDE's and editors. Maybe some of that information can be applied to Geany. Sorry I have never used Geany myself, only saw it run about 4 years ago.

Regards,
- Graeme -

"Philippe" wrote

@cfg I read about that option in a previous message of the thread ... clearly

a better ideia!!! ... I´ll use it for sure!

taking advantage of the oportunity. when one type fpc in the command

line, he/she gets:

It should be listed if you show the help using "-h" parameter.

Regards,
Sven

Well, it's only listed in trunk since r28187 (7 July)... I had to modify the compiler in order to allow displaying an option not starting with '-'.

Tomas

fpc -h

Free Pascal Compiler version 2.6.4 [2014/03/06] for i386
Copyright (c) 1993-2014 by Florian Klaempfl and
others
c:FPC2.6.4bini386-Win32ppc386.exe [options] <inputfile> [options]
Put + after a boolean switch option to enable it, - to disable it
-a The compiler doesn't delete the generated assembler file -al
List sourcecode lines in assembler file
-an List node info in assembler
file
-ar List register allocation/release info in assembler file -at
List temp allocation/release info in assembler file -A<x> Output
format:
-Adefault Use default assembler
-Aas Assemble using GNU AS

-Amacho Mach-O (Darwin, Intel 32 bit) using internal writer -Anasmcoff
COFF (Go32v2) file using Nasm
-Anasmelf ELF32 (Linux) file using Nasm

-Anasmwin32Win32 object file using Nasm
-AnasmwdosxWin32/WDOSX object
file using Nasm
-Awasm Obj file using Wasm (Watcom)
-Anasmobj Obj file
using Nasm
-Amasm Obj file using Masm (Microsoft)
-Atasm Obj file
using Tasm (Borland)
-Aelf ELF (Linux) using internal writer
-Acoff
COFF (Go32v2) using internal writer
-Apecoff PE-COFF (Win32) using
internal writer
-b Generate browser info
-bl Generate local symbol
info
-B Build all modules
-C<x> Code generation options:
-C3<x> Turn
on ieee error checking for constants
-Ca<x> Select ABI, see fpc -i for
possible values
-Cb Generate big-endian code
-Cc<x> Set default
calling convention to <x>
-CD Create also dynamic library (not
supported)
-Ce Compilation with emulated floating point opcodes -Cf<x>
Select fpu instruction set to use, see fpc -i for possible values

-CF<x> Minimal floating point constant precision (default, 32, 64) -Cg
Generate PIC code
-Ch<n> <n> bytes heap (between 1023 and 67107840)

-Ci IO-checking
-Cn Omit linking stage
-Co Check overflow of integer
operations
-CO Check for possible overflow of integer operations

-Cp<x> Select instruction set, see fpc -i for possible values

-CP<x>=<y> packing settings
-CPPACKSET=<y> <y> set allocation: 0, 1 or
DEFAULT or NORMAL, 2, 4 and 8
-Cr Range checking
-CR Verify object
method call validity
-Cs<n> Set stack checking size to <n>
-Ct Stack
checking (for testing only, see manual)
-CX Create also smartlinked
library
-d<x> Defines the symbol <x>
-D Generate a DEF file
-Dd<x>
Set description to <x>
-Dv<x> Set DLL version to <x>
-e<x> Set path to
executable
-E Same as -Cn
-fPIC Same as -Cg
-F<x> Set file names and
paths:
-Fa<x>[,y] (for a program) load units <x> and [y] before uses is parsed
-Fc<x> Set input codepage to <x>
-FC<x> Set RC compiler binary
name to <x>
-Fd Disable the compiler's internal directory cache -FD<x>
Set the directory where to search for compiler utilities -Fe<x>
Redirect error output to <x>
-Ff<x> Add <x> to framework path (Darwin
only)
-FE<x> Set exe/unit output path to <x>
-Fi<x> Add <x> to include
path
-Fl<x> Add <x> to library path
-FL<x> Use <x> as dynamic linker

-Fm<x> Load unicode conversion table from <x>.txt in the compiler dir

-Fo<x> Add <x> to object path
-Fr<x> Load error message file <x>

-FR<x> Set resource (.res) linker to <x>
-Fu<x> Add <x> to unit path

-FU<x> Set unit output path to <x>, overrides -FE
-FW<x> Store
generated whole-program optimization feedback in <x> -Fw<x> Load
previously stored whole-program optimization feedback from <x> -g
Generate debug information (default format for target) -gc Generate
checks for pointers
-gh Use heaptrace unit (for memory leak/corruption debugging)
-gl Use line info unit (show more info with backtraces)

-go<x> Set debug information options
-godwarfsets Enable DWARF 'set'
type debug information (breaks gdb < 6.5)
-gostabsabsincludes Store
absolute/full include file paths in Stabs
-godwarfmethodclassprefix
Prefix method names in DWARF with class name
-gp Preserve case in stabs
symbol names
-gs Generate Stabs debug information
-gt Trash local
variables (to detect uninitialized uses)
-gv Generates programs
traceable with Valgrind
-gw Generate DWARFv2 debug information (same as
-gw2)
-gw2 Generate DWARFv2 debug information
-gw3 Generate DWARFv3
debug information
-gw4 Generate DWARFv4 debug information
(experimental)
-i Information
-iD Return compiler date
-iV Return
short compiler version
-iW Return full compiler version
-iSO Return
compiler OS
-iSP Return compiler host processor
-iTO Return target OS

-iTP Return target processor
-I<x> Add <x> to include path
-k<x> Pass
<x> to the linker
-l Write logo
-M<x> Set language mode to <x>
-Mfpc
Free Pascal dialect (default)
-Mobjfpc FPC mode with Object Pascal
support
-Mdelphi Delphi 7 compatibility mode
-Mtp TP/BP 7.0
compatibility mode
-Mmacpas Macintosh Pascal dialects compatibility
mode
-n Do not read the default config files
-N<x> Node tree
optimizations
-Nu Unroll loops
-o<x> Change the name of the executable
produced to <x>
-O<x> Optimizations:
-O- Disable optimizations
-O1
Level 1 optimizations (quick and debugger friendly) -O2 Level 2
optimizations (-O1 + quick optimizations)
-O3 Level 3 optimizations
(-O2 + slow optimizations)
-Oa<x>=<y> Set alignment
-Oo[NO]<x> Enable
or disable optimizations, see fpc -i for possible values -Op<x> Set
target cpu for optimizing, see fpc -i for possible values -OW<x>
Generate whole-program optimization feedback for optimization <x>, see fpc -i for possible values
-Ow<x> Perform whole-program optimization
<x>, see fpc -i for possible values
-Os Optimize for size rather than
speed
-pg Generate profile code for gprof (defines FPC_PROFILE) -R<x>
Assembler reading style:
-Rdefault Use default assembler for target

-Ratt Read AT&T style assembler
-Rintel Read Intel style assembler

-S<x> Syntax options:
-S2 Same as -Mobjfpc
-Sc Support operators like
C (*=,+=,/= and -=)
-Sa Turn on assertions
-Sd Same as -Mdelphi

-Se<x> Error options. <x> is a combination of the following: <n> :
Compiler halts after the <n> errors (default is 1) w : Compiler also
halts after warnings
n : Compiler also halts after notes
h : Compiler
also halts after hints
-Sg Enable LABEL and GOTO (default in -Mtp and
-Mdelphi)
-Sh Use ansistrings by default instead of shortstrings -Si
Turn on inlining of procedures/functions declared as "inline" -Sk Load
fpcylix unit
-SI<x> Set interface style to <x>
-SIcom COM compatible
interface (default)
-SIcorba CORBA compatible interface
-Sm Support
macros like C (global)
-So Same as -Mtp
-Ss Constructor name must be
init (destructor must be done)
-Sx Enable exception keywords (default
in Delphi/ObjFPC modes)
-Sy @<pointer> returns a typed pointer, same as
$T+
-s Do not call assembler and linker
-sh Generate script to link on
host
-st Generate script to link on target
-sr Skip register
allocation phase (use with -alr)
-T<x> Target operating system:

-Tdarwin Darwin/Mac OS X
-Temx OS/2 via EMX (including EMX/RSX
extender)
-Tfreebsd FreeBSD
-Tgo32v2 Version 2 of DJ Delorie DOS
extender
-Tiphonesim iPhoneSimulator from iOS SDK 3.2+ (older versions: -Tdarwin)
-Tlinux Linux
-Tnetbsd NetBSD
-Tnetware Novell Netware
Module (clib)
-Tnetwlibc Novell Netware Module (libc)
-Topenbsd
OpenBSD
-Tos2 OS/2 / eComStation
-Tsunos SunOS/Solaris
-Tsymbian
Symbian OS
-Tsolaris Solaris
-Twatcom Watcom compatible DOS extender

-Twdosx WDOSX DOS extender
-Twin32 Windows 32 Bit
-Twince Windows CE

-u<x> Undefines the symbol <x>
-U Unit options:
-Un Do not check where
the unit name matches the file name
-Ur Generate release unit files
(never automatically recompiled)
-Us Compile a system unit
-v<x> Be
verbose. <x> is a combination of the following letters: e : Show errors
(default) 0 : Show nothing (except errors)
w : Show warnings u : Show
unit info
n : Show notes t : Show tried/used files
h : Show hints c :
Show conditionals
i : Show general info d : Show debug info
l : Show
linenumbers r : Rhide/GCC compatibility mode
s : Show time stamps q :
Show message numbers
a : Show everything x : Executable info (Win32
only)
b : Write file names messages p : Write tree.log with parse tree

with full path v : Write fpcdebug.txt with
lots of debugging info

m<x>,<y> : Don't show messages numbered <x> and <y> -W<x>
Target-specific options (targets)
-WA Specify native type application
(Windows)
-Wb Create a bundle instead of a library (Darwin)
-WB Create
a relocatable image (Windows, Symbian)
-WBxxxx Set image base to xxxx
(Windows, Symbian)
-WC Specify console type application (EMX, OS/2,
Windows)
-WD Use DEFFILE to export functions of DLL or EXE (Windows)

-We Use external resources (Darwin)
-WF Specify full-screen type
application (EMX, OS/2)
-WG Specify graphic type application (EMX,
OS/2, Windows)
-Wi Use internal resources (Darwin)
-WI Turn on/off the
usage of import sections (Windows)
-WM<x> Minimum Mac OS X deployment
version: 10.4, 10.5.1, ... (Darwin)
-WN Do not generate relocation
code, needed for debugging (Windows)
-WP<x> Minimum iOS deployment
version: 3.0, 5.0.1, ... (iphonesim)
-WR Generate relocation code
(Windows)
-WX Enable executable stack (Linux)
-X Executable options:

-Xc Pass --shared/-dynamic to the linker (BeOS, Darwin, FreeBSD, Linux)

-Xd Do not search default library path (sometimes required for cross-compiling when not using -XR)
-Xe Use external linker
-Xg Create
debuginfo in a separate file and add a debuglink section to executable

-XD Try to link units dynamically (defines FPC_LINK_DYNAMIC) -Xi Use
internal linker
-Xm Generate link map
-XM<x> Set the name of the
'main' program routine (default is 'main')
-XP<x> Prepend the binutils
names with the prefix <x>
-Xr<x> Set the linker's rlink-path to <x>
(needed for cross compile, see the ld manual for more information) (BeOS, Linux)
-XR<x> Prepend <x> to all linker search paths (BeOS, Darwin, FreeBSD, Linux, Mac OS, Solaris)
-Xs Strip all symbols from
executable
-XS Try to link units statically (default, defines FPC_LINK_STATIC)
-Xt Link with static libraries (-static is passed to linker)
-XX Try to smartlink units (defines FPC_LINK_SMART)

-? Show
this help
-h Shows this help without waiting

Sven Barth wrote

Am 03.10.2014 03:37 schrieb "Philippe"

:

> > @cfg > > I read about that option

in a previous message of the thread ... clearly a better ideia!!! ... I´ll use it for sure!

> > taking advantage of the oportunity. when

one type fpc in the command line, he/she gets:

> > > >

D:psl9c9>fpc

> Free Pascal Compiler version 2.6.4 [2014/03/06] for

i386

> Copyright (c) 1993-2014 by Florian Klaempfl and others >

c:FPC2.6.4bini386-Win32ppc386.exe [options] <inputfile> [options]

about @cfg !

> > that is the reason while I never used it! It

should be listed if you show the help using "-h" parameter.

Regards,

Sven _______________________________________________

fpc-pascal maillist -

http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal [1]

Links:
------
[1]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Philippe wrote

fpc -h Free Pascal Compiler version 2.6.4 [2014/03/06] for i386

.
.

'@' is indeed listed in help only in recent trunk compiler (since July).

Tomas

clearly

Right... Forgot that :/

Regards,
Sven

Hello.

I use Geany and fpGUI for ages now. ;-)

All you have to do =>

In Geany:

- Click on "Define construct command => In "Compile command" => fpc "%f" @extrafpc.cfg

extrafpc.cfp is a text file with all your -fu and -fi needed.

Here example of a fpGUI extrafpc.cfg =>

>>>>>>>>>

-fPIC
-Fi/home/fred/fpGUI-develop/src/
-Fi/home/fred/fpGUI-develop/src/corelib/
-Fi/home/fred/fpGUI-develop/src/corelib/x11/
-Fu/home/fred/fpGUI-develop/src/
-Fu/home/fred/fpGUI-develop/src/corelib/
-Fu/home/fred/fpGUI-develop/src/gui/
-Fu/home/fred/fpGUI-develop/src/corelib/x11/
-FUunits/
-FE./

>>>>>>>>>>>>>

Fred

-----
Many thanks ;-)