Hi,

I'm trying to reduce the compiler output for cron jobs.

I have tried to specify -v0 or even -v- -v0 but still the compiler outputs loads of 'Hint' and 'Warning' message about unused parameters, unused units, deprecated methods etc.

I made sure no -v is specified in my ~.fpc.cfg as well, but still the compiler seems to ignore my -v0 preference on the command line.

What else can I try?

I'm using FPC 2.6.2 under FreeBSD.

Regards,
- Graeme -

I use -vi-n-h- for my release builds, which removes info, notes and hints, otherwise it becomes hard to see the wood from the trees!

Henry

Well, I can remove all output altogether by using -v0 and -l- (tested with both 2.6.2 and 2.6.4 under Win32; I don't think that the platform should matter much here).

Tomas

Henry Vermaak wrote

I use -vi-n-h- for my release builds, which removes info, notes and hints, otherwise it becomes hard to see the wood from the trees!

Exactly what I want to try and do, but it seems FPC is really stubborn under FreeBSD. I tried the exact same -v parameters as you suggested, but it made no difference. :-/

Here is my build script.

------------[ build-64.sh ]-----------------
#!/bin/sh
# Build script for tiOPF using 64bit Free Pascal Compiler BASEDIR="/data/devel"
FPC="$BASEDIR/fpc-2.6.2/x86_64-freebsd/bin/ppcx64" FPCVER=`$FPC -iV`
FPCCPU=`$FPC -iTP`
FPCHOST=`$FPC -iTO`
TIOPF="$BASEDIR/tiopf_dailybuilds/tiopf"
FBLIB="$TIOPF/3rdParty/FBLib"
ZEOS="$BASEDIR/opensource/zeos_svn"

$FPC -MObjFPC -S2cai -O1 -gl -vi-n-h- -B \
-Fu$FBLIB \
-Fi$FBLIB \
-Fu$ZEOS/src/core \
-Fu$ZEOS/src/component \
-Fu$ZEOS/src/dbc \
-Fu$ZEOS/src/parsesql \
-Fu$ZEOS/src/plain \
-Fu$ZEOS/packages/lazarus/ \
-Fi$TIOPF/Core/ \
-Fu$TIOPF/Core/ \
-Fu$TIOPF/Options/ \
-Fu$TIOPF/GUI/ \
-FU$TIOPF/Compilers/FPC/lib/$FPCCPU-$FPCHOST/ \
-dLINK_CSV -dLINK_TAB -dLINK_XMLLIGHT -dLINK_SQLDB_IB \ -dLINK_FBL -dLINK_ZEOS_FB -dLINK_ZEOS_MYSQL50 \
-dUseCThreads \
$TIOPF/Compilers/FPC/tiOPF.pas

----------------[ end ]------------------

And this is the output it generates..... Lots of noise!

------------------------------------------------
[freebsd (tiopf2)]$ ./build-64.run
Free Pascal Compiler version 2.6.2 [2013/02/10] for x86_64
Copyright (c) 1993-2012 by Florian Klaempfl and others
tiUtils.pas(3000,3) Hint: Local const "subdomain_chars" is not used
tiUtils.pas(3261,43) Hint: Local variable "LBytes1" does not seem to be
initialized
tiUtils.pas(3262,43) Hint: Local variable "LBytes2" does not seem to be
initialized
tiCompress.pas(103,45) Hint: Function result variable does not seem to
be initialized
tiCompress.pas(115,47) Hint: Function result variable does not seem to
be initialized
tiBase64.pas(246,37) Hint: Local variable "scanBuf" does not seem to be
initialized
tiBase64.pas(273,27) Hint: Local variable "endBytes" does not seem to be
initialized
tiBase64.pas(346,33) Hint: Local variable "ReadBuf" does not seem to be
initialized
tiBase64.pas(95,19) Hint: Parameter "Offset" not used
tiBase64.pas(95,36) Hint: Parameter "Origin" not used
tiStreams.pas(571,44) Hint: Local variable "InputBuffer" does not seem
to be initialized
tiStreams.pas(646,20) Hint: Conversion between ordinals and pointers is
not portable
tiStreams.pas(646,88) Hint: Conversion between ordinals and pointers is
not portable
tiStreams.pas(764,37) Hint: Conversion between ordinals and pointers is
not portable
tiStreams.pas(332,3) Hint: Local const "MIME_BUFFER_SIZE" is not used
tiLog.pas(284,43) Hint: Parameter "ASeverity" not used
tiLog.pas(293,45) Hint: Parameter "ARaiseException" not used
tiLog.pas(294,50) Hint: Parameter "ARaiseException" not used
tiLog.pas(779,26) Hint: Conversion between ordinals and pointers is not
portable
tiLog.pas(137,33) Hint: Parameter "ADateTime" not used
tiLog.pas(138,34) Hint: Parameter "AMessage" not used
tiPool.pas(119,3) Hint: Local const "CMaxPoolSize" is not used
tiPool.pas(120,3) Hint: Local const "CMinPoolSize" is not used

....snip....

tiOPF.pas(18,3) Hint: Unit "tiFilteredObjectList" not used in tiOPF
tiOPF.pas(18,41) Hint: Unit "tiModelMediator" not used in tiOPF
tiOPF.pas(18,58) Hint: Unit "tiQueryDataset" not used in tiOPF
tiOPF.pas(18,74) Hint: Unit "tiOPFSqlScript" not used in tiOPF
tiOPF.pas(19,15) Hint: Unit "tiLogToDebugSvr" not used in tiOPF
tiOPF.pas(19,32) Hint: Unit "tiPersistenceLayers" not used in tiOPF
tiOPF.pas(19,53) Hint: Unit "tiWebServerClientConnectionDetails" not
used in tiOPF
tiOPF.pas(20,3) Hint: Unit "tiCRC32" not used in tiOPF

-------------------------------------------------

This is frustrating as hell. :)

Regards,
- Graeme -

Some random ideas:

maybe it's loading some config file anyway.
Do a strace and see if it opens a config file.

secondly: There is no {$HINTS ON} or so in the sources ?

Michael.

Michael Van Canneyt wrote

maybe it's loading some config file anyway. Do a strace and see if it opens a config file.

'strace' is not available/supported by 64-bit FreeBSD (only 32-bit FreeBSD). But I did remember that FPC has a very verbose output option. Amazingly that -v parameter did make FPC output more details - so at least FPC does seem to read my -v options (at least some of them).

Here is a very small snippet of what I got from using the -vav parameter.

...snip...
[0.000] Macro defined: CPUAMD64
[0.000] Macro defined: CPU64
[0.000] Configfile search: /home/graemeg/.fpc.cfg
[0.000] Reading options from file /home/graemeg/.fpc.cfg [0.000] Start of reading config file /home/graemeg/.fpc.cfg [0.000] interpreting file option "#"
[0.000] interpreting file option "# Example fpc.cfg for Free Pascal Compiler"
...snip...

That is the only config file it found and loaded. That config file contains a -v- option, but even removing that option completely makes no difference.

Could this be a bug in the FreeBSD version of FPC? That some of the -v options simply don't work under FreeBSD?

Could somebody else with FreeBSD access test the -v parameter? That way we can confirm if it is something odd on my system (and I'll keep searching), or a general FPC issue.

secondly: There is no {$HINTS ON} or so in the sources ?

I never use that option inside units. But to made double sure, I just did a search, and can confirm no such directive exists in any of the source code I'm trying to compile.

Regards,
- Graeme -

Graeme Geldenhuys wrote

That is the only config file it found and loaded. That config file contains a -v- option, but even removing that option completely makes no difference.

-v- doesn't do anything, it's -v0 that should switch off all output (except for errors and fatal errors). Someone else reported the same bug very recently though (http://bugs.freepascal.org/view.php?id=25946 ), so you're not the only one experiencing this.

Jonas

Hi Graeme,

maybe you should do a
a
$FPC -va -h | grep "Reading options from"
and check which configuration file is loaded.

But anyhow, the option unit contains code that
normally ensure that command line options always
win over config file options.
However, Michael is right in asking about {$hints on} inside source, because, in such case
the command line -v0 has no effect.

Pierre Muller

In our previous episode, Graeme Geldenhuys said:

That's because it is a port. The normal tool to use on BSDs is ktrace. (and on some other SYSV derived systems, like Solaris, it is called truss IIRC)

But I did remember that FPC has a very verbose output option.

Could this be a bug in the FreeBSD version of FPC? That some of the -v options simply don't work under FreeBSD?

I doubt it, filtering log output isn't really platform dependent.

Jonas Maebe wrote

-v- doesn't do anything, it's -v0 that should switch off all output (except for errors and fatal errors).

Thanks. So what is the difference between -ve and -v0? From the compiler help output it sounds like they do the same thing. But neither of them works in my case.

-v<x> Be verbose. <x> is a combination of the following letters: e : Show errors (default) 0 : Show nothing (except errors)

Someone else reported the same bug very recently though (http://bugs.freepascal.org/view.php?id=25946 ), so you're not the only one experiencing this.

Okay. I added a comment and a link to this discussion.

Regards,
- Graeme -

Marco van de Voort wrote

I doubt it, filtering log output isn't really platform dependent.

That is what I assume too. So the issue is probably across all platforms then (but I haven't tested elsewhere yet).

Regards,
- Graeme -

Pierre Free Pascal wrote

$FPC -va -h | grep "Reading options from" and check which configuration file is loaded.

That is pretty much what I did...

----------------------
[freebsd (tiopf2)]$ fpc -va -h | grep "Reading options from" [0.000] Reading options from file /home/graemeg/.fpc.cfg [freebsd (tiopf2)]$
----------------------

However, Michael is right in asking about {$hints on}

Like is said in my reply to Michael, I searched through all related code, and there is no such directive used.

Regards,
- Graeme -

-ve does not switch anything off, it only enables showing errors (e.g., if it was disabled first via -ve-). -v0 switches off everything but error reporting.

Jonas

...Supposedly, in view of the bugreport and trouble experienced by Graeme ;)

That said, I find it strange, because I have all verbosity except errors switched off, and it works.

Michael.

Could you test by disabling the usage of a config file (-n)? You'll need to pass all paths using -Fu then, so I suggest to use a simple test project which prints hints, etc. without "-n" and then test that with "-n".

Regards,
Sven

Jonas Maebe wrote

-ve does not switch anything off, it only enables showing errors

Ah, now I understand. Thanks for the info.

For an immediate solution (work-around), I enabled message numbers (-vq), and then created a long list of -vm[x],[y] options to suppress the messages I wanted to hide in the first place. This has worked.

So it seems at least some of the -v options are working, but definitely not all of them.

Regards,
- Graeme -

Sven Barth wrote

Could you test by disabling the usage of a config file (-n)? You'll need to pass all paths using -Fu then,

No problem. Just did the test with -n and it made no difference when it comes to the -v parameter options. The -vh- , -vw- and -v0 parameters are all ignored. I still get the usual verbose output.

Here is my build script as I used it for this test.

----8<-------------8<-------------8<-------------8<-------------8<---- #!/bin/sh
# Build script for tiOPF using 64bit Free Pascal Compiler BASEDIR="/data/devel"
FPC="$BASEDIR/fpc-2.6.2/x86_64-freebsd/bin/ppcx64" FPCVER=`$FPC -iV`
FPCCPU=`$FPC -iTP`
FPCHOST=`$FPC -iTO`
TIOPF="$BASEDIR/tiopf_dailybuilds/tiopf"
FBLIB="$TIOPF/3rdParty/FBLib"
ZEOS="$BASEDIR/opensource/zeos_svn"

# set variables as they would have been in fpc.cfg fpcversion="2.6.2"
fpctarget="x86_64-freebsd"

# Work-around to suppress all unwanted messages
#$FPC -MObjFPC -S2cai -O1 -gl -vh- -vw- -ve -vq
-vm5023,505#7,5058,5060,5024,5028,4055 -B \

$FPC -MObjFPC -S2cai -O1 -gl -vh- -vw- -v0 -n -B \

-Fu/data/devel/fpc-$fpcversion/$fpctarget/lib/fpc/$fpcversion/units/$fpctarget/* \
-Fl/lib:/usr/lib:/usr/local/lib \
-Fl/data/devel/fpc-$fpcversion/lib/fpc/$fpcversion/lib/$fpctarget \ -FD/data/devel/fpc-$fpcversion/$fpctarget/bin/ \
-Fu$FBLIB \
-Fi$FBLIB \
-Fu$ZEOS/src/core \
-Fu$ZEOS/src/component \
-Fu$ZEOS/src/dbc \
-Fu$ZEOS/src/parsesql \
-Fu$ZEOS/src/plain \
-Fu$ZEOS/packages/lazarus/ \
-Fi$TIOPF/Core/ \
-Fu$TIOPF/Core/ \
-Fu$TIOPF/Options/ \
-Fu$TIOPF/GUI/ \
-FU$TIOPF/Compilers/FPC/lib/$FPCCPU-$FPCHOST/ \
-dLINK_CSV -dLINK_TAB -dLINK_XMLLIGHT -dLINK_SQLDB_IB \ -dLINK_FBLx -dLINK_ZEOS_FB -dLINK_ZEOS_MYSQL50 \
-dUseCThreads \
$TIOPF/Compilers/FPC/tiOPF.pas

----8<-------------8<-------------8<-------------8<-------------8<----

And the output is still verbose

-------------------------------------------
[freebsd (tiopf2)]$ ./opf_package-64.run
tiUtils.pas(3000,3) Hint: Local const "subdomain_chars" is not used tiUtils.pas(3261,43) Hint: Local variable "LBytes1" does not seem to be initialized
tiUtils.pas(3262,43) Hint: Local variable "LBytes2" does not seem to be initialized
tiCompress.pas(103,45) Hint: Function result variable does not seem to be initialized
tiCompress.pas(115,47) Hint: Function result variable does not seem to be initialized
tiBase64.pas(246,37) Hint: Local variable "scanBuf" does not seem to be initialized
.....snip.....
tiOPF.pas(19,32) Hint: Unit "tiPersistenceLayers" not used in tiOPF tiOPF.pas(19,53) Hint: Unit "tiWebServerClientConnectionDetails" not used in tiOPF
tiOPF.pas(20,3) Hint: Unit "tiCRC32" not used in tiOPF [freebsd (tiopf2)]$
-------------------------------------------

Regards,
- Graeme -

As mentioned yesterday, I tested it under Win32 with the 2.6.4 compiler and it worked according to specification. It apparently works well for Jonas too on his Mac OS X machine (according to his note added to the bug report).

We clearly need to find out more information about the differences leading to the incorrect behaviour. That's why I asked the bug reporter to provide information about his platform (one difference which I can see that Graeme uses the x86_64 version - not that it should make any difference, but all possibilities need to be analyzed), check if -n changes anything and test if it works the same also with the simplest source files.

Tomas

.
.

Graeme, can you please try if you get the same behaviour with simple source files like the following:

-----------
var
 C: cardinal;
begin
 C := -1;
end.
===========

By default (i.e. with -n and no -v* whatsoever), this should not show anything. With the default configuration file, it should show one hint (C assigned but not used) and one warning (range check). With the configuration file and -v0 it should not show anything again (apart from the compiler version if you have the default of -l in your configuration file). This is just to check if the behaviour depends on the compiled sources in any way.

Tomas

Hi Tomas,

Tomas Hajny wrote

file). This is just to check if the behaviour depends on the compiled sources in any way.

You were on to something. Using your simple unit as an example, all the various -v options work perfectly.

That made me double check the code I'm compiling - then I found something. When I searched through all the source code [the first time] for the text '$HINTS ON', my searching tool accidentally had regex support enabled, thus the $ symbol was interpreted differently, and resulted in no files with such text found. Doing the search again, and this time disabling regex support, it revealed that I had a few units that used the $HINTS directive.

My usage of the $HINTS directive was to switch hints off for one or more lines of code, then switch hints back on. An example of this would be around the FillChar() call.

I checked the FPC 2.6.2 documentation about the $HINTS directive and it doesn't say what hints get switched on. But from a quick experimentation, it seems {$HINTS ON} is equivalent to -vewnhi (it doesn't just restore the previous hint verbosity state, it overrides and sets a new verbosity state). And knowing now that {$HINTS ON} takes priority over everything else, it explains the reason why my command line parameter for -v<whatever> or what was defined in fpc.cfg was totally useless.

So there was no FPC bug after all, but maybe the documentation for $HINTS could be extended in this regards - stating that it doesn't restore the previous verbosity level, it sets a new one. It could be helpful to other developers in future.

So in the end my only solution is to use -vm with a list of message numbers I want to suppress.

Thanks to everybody that tried to help me - much appreciated.

Regards,
- Graeme -

On Sun, April 6, 2014 02:59, Graeme Geldenhuys wrote:

Hi Graeme,

.
.

So there was no FPC bug after all, but maybe the documentation for $HINTS could be extended in this regards - stating that it doesn't restore the previous verbosity level, it sets a new one. It could be helpful to other developers in future.

.
.

I'm glad that we managed to resolve the mystery finally. :-) Regarding restoring the previous status for showing hints - do you mean {$HINTS DEFAULT}?

Tomas

Am 06.04.2014 12:42 schrieb "Graeme Geldenhuys" <

: My usage of the $HINTS directive was to switch hints off for one or more lines of code, then switch hints back on. An example of this would be around the FillChar() call.

I wrote you that already some time ago: to be on the safe side you should use the following:

=== code begin ===

{$push}
{$hints off}
// code with disabled hints
{$pop}

=== code end ===

Pop will restore the state that it was at the Push directive.

Just in case: not Delphi compatible.

Regards,
Sven

Sven Barth wrote

Pop will restore the state that it was at the Push directive.

My appologies, I completely forgot about that. Thanks for reminding me. I've made a note in my offline documentation so as not to forget this tip again.

Just in case: not Delphi compatible.

In this case I can't use it, because this project must stay Delphi compatible. Still a very useful tip though. Thanks again.

Regards,
- Graeme -

In our previous episode, Graeme Geldenhuys said:

> Just in case: not Delphi compatible. In this case I can't use it, because this project must stay Delphi compatible. Still a very useful tip though. Thanks again.

Then you must test with $ifopt, set a define if it is enabled, and then
restore it if the define is set afterwards and undef the define.

It is more verbose but it works, something like:

{$undef something}
{$ifopt hints } // don't know exact syntax}
  {$define something}
{$endif}
{$hints on}

.... code

{$ifndef something}
  {$hints off}
{$endif}

Problem is that this construct doesn't nest, and gets really complicated for multiple settings.