Hello all,

In my application, I want to use a custom fpc.cfg. As I work only with commandline tools, this is an important file for me.

I have used fpcmkcfg to generate a brand new fpc.cfg.

In my application, I have a directory for configuration files. I thought in placing fpc.cfg there in stead of the same directory of the executable.

What I want to know is: is there a commandline parameter to specify a new name or, at least, a new directory to fpc.cfg file?

For example, in stead of placing fpc.cfg in ./, I want to place it in ./Settings.

I use fpc 2.6.4.

luciano de souza wrote

What I want to know is: is there a commandline parameter to specify a new name or, at least, a new directory to fpc.cfg file?

Yes, there is (I suspect it's fpc @/path/to/your/fpc.cfg) but the default config files (e.g. /etc/fpc/fpc.cfg or something) will still be read.
You'll need to use fpc with the -n option to avoid that.

Hi,

luciano de souza wrote

What I want to know is: is there a commandline parameter to specify a new name or, at least, a new directory to fpc.cfg file?

There's an environment variable called PPC_CONFIG_PATH you can set to tell the compiler the new config location. It's detailed in the documentation, here:

http://www.freepascal.org/docs-html/user/usersu10.html

Hope this helps,

luciano de souza wrote

What I want to know is: is there a commandline parameter to specify a new name or, at least, a new directory to fpc.cfg file?

-n @/full/path/to/fpc.cfg

The first parameter instructs the compiler not to load the default fpc.cfg file, the second one to load a configuration from the custom one.

Jonas

Incidentally, how does one get a list of fpc's options? I don't mean fpc -h since that actually shows ppcXXX's options, but how does one get minimal info on fpc itself such as a reminder of the -V option?

I don't think there's a way, except for looking at the source.

Henry

In trunk, fpc -h shows all options supported by either fpc or ppcXXX (technically, ppcXXX still shows the list, but it includes fpc specific options if invoked from fpc). The part handled specifically by fpc should not be of such a high interest normally, but it may be obtained by diffing the output of both.

BTW, the parameter '@' mentioned here is apparently not shown in the options list produced by either -? or -h... ;-)

Tomas

Not in released versions indeed, only in trunk.

Tomas

I agree that it's obscure, but there was discussion of -V a few weeks ago in the context of starting Lazarus and I needed a reminder yesterday. source, I note also -PP and -PB with the apparent "health warning" that they aren't qualified by the -V parameter.

I meant specifically that most users should not need to differentiate between options handled by fpc and options handled by ppcXXX.

Anyway - if you want to find out options specific to the fpc helper (and/or you don't have a compiled trunk compiler readily available), you can also use:

grep -e "^F\*" < fpcsrc/compiler/msg/errore.msg | cut -c3- | sed "s/^1/-/" | sed "s/^2/ -/" | sed "s/_/ /"

(again, you need the trunk version of errore.msg as available e.g. from http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/compiler/msg/errore.msg?revision=28152&view=co)

That gives the following list:

-P<x> Target CPU / compiler related options:
-PB Show default compiler binary
-PP Show default target cpu
-P<x> Set target CPU
(arm,i386,m68k,mips,mipsel,powerpc,powerpc64,sparc,x86_64 -V<x> Append '-<x>' to the used compiler binary name (e.g. for version) -Xp<x> First search for the compiler binary in the directory <x>

Tomas

Yes, I should know better than to reply here on this, but I am fascinated by how this one line UNIX command can parse the error message source file and extract the option information.

In general would it be more efficient to combine all the sed commands into one with multiple -e options, saving the extra pipes between commands, or would there be drawbacks?

grep -e "^F\*" < fpcsrc/compiler/msg/errore.msg | cut -c3- | sed -e "s/^1/-/" -e "s/^2/ -/" -e "s/_/ /"

Apologies for being off-topic. I am interested in what it is safely compatible to do across various environments in clever compile scripts.

.
.

<OT>Combining it would be indeed more efficient; I'm no expert on sed and simply didn't bother to try being efficient . I don't think that there should be any drawbacks, but I don't want to pretend to have any special knowledge of possible differences in various sed implementations.</OT>

BTW, I just added the previously missing information about option '@' to the help pages in trunk (together with some improvements necessary to show this option properly).

Tomas

Sed, awk, tr and a number of other unix utilities are, perhaps fortunately, used comparatively seldom these days. Since the command lines are notoriously cryptic, I think there's a strong argument for keeping individual stages of a filtering operation as simple as possible; this also allows stages to be lopped easily for debugging.

http://xkcd.com/1168/

And that particularly applies in a context where a significant proportion of readers don't use unix, and have no inclination to try.