Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2011-09

Include files with double names

4 messages · 2 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Joost van der Sluis

Hi all,

I've found a new problem with include-names with the same name. Please try the following in a freshly compiled svn-checkout. (This is on linux/x86_64, but the idea is clear)

cd packages/libxml
ppcx64 -FUunits/x86_64-linux -Fu../../rtl/units/x86_64-linux -Fisrc src/xmlxsdparser.pas

The result:

Free Pascal Compiler version 2.7.1 [2011/09/06] for x86_64 Copyright (c) 1993-2011 by Florian Klaempfl and others Target OS: Linux for x86-64
Compiling src/xmlxsdparser.pas
PPU Loading /home/CNOC/joost/svn/fpc-trunk/rtl/units/x86_64-linux/classes.ppu PPU Source: classes.pp not found
PPU Source: classesh.inc not found
PPU Source: classes.inc not found
PPU Source: util.inc not found
PPU Source: bits.inc not found
PPU Source: streams.inc not found
File ./src/parser.inc is newer than the one used for creating PPU file /home/CNOC/joost/svn/fpc-trunk/rtl/units/x86_64-linux/classes.ppu PPU Source: ./src/parser.inc time 2011/05/19 12:54:47 * PPU Source: collect.inc not found
PPU Source: lists.inc not found
PPU Source: stringl.inc not found
PPU Source: tthread.inc not found
PPU Source: persist.inc not found
PPU Source: sllist.inc not found
PPU Source: resref.inc not found
PPU Source: compon.inc not found
PPU Source: action.inc not found
PPU Source: dm.inc not found
PPU Source: cregist.inc not found
PPU Source: intf.inc not found
PPU Source: filer.inc not found
PPU Source: reader.inc not found
PPU Source: writer.inc not found
PPU Source: twriter.inc not found
classes.pp(21,11) Fatal: Can't find unit Classes used by xmlxsdparser Fatal: Compilation aborted

The problem is that the parser.inc from the rtl/classes unit is compared with the parser.inc in src. When the '-Fisrc' part from the command line is removed, the compilation is successful. (This is what the Makefiles do, when you compile using fpmake, the problem above may occur)

Can someone reproduce this? And what to do now? I've even did a touch on the rtl/objpas/parser.inc, but that doesn't help.

My Lazarus blog: http://www.lazarussupport.com/lazarus/weblog

Reply by email

Jonas Maebe
to Joost van der Sluis
Joost van der Sluis wrote
Can someone reproduce this? And what to do now? I've even did a touch on the rtl/objpas/parser.inc, but that doesn't help.

If you perform a top level "make all", the RTL and packages are compiled with -Ur so that it never gets recompiled. If you compile them manually, you should add that parameter yourself in most cases (unless you are debugging a bug regarding include files in the RTL). This problem is not specific to the RTL vs packages, it can also happen with any FPC-supplied unit and third party sources (which is why the -Ur parameter was implemented and activated by default when doing a "make all").

Jonas

Reply by email

Joost van der Sluis
to Jonas Maebe
Jonas Maebe wrote 6 lines
On 06 Sep 2011, at 21:48, Joost van der Sluis wrote: > Can someone reproduce this? And what to do now? I've even did a touch on > the rtl/objpas/parser.inc, but that doesn't help. If you perform a top level "make all", the RTL and packages are compiled with -Ur so that it never gets recompiled. If you compile them manually, you should add that parameter yourself in most cases (unless you are debugging a bug regarding include files in the RTL). This problem is not specific to the RTL vs packages, it can also happen with any FPC-supplied unit and third party sources (which is why the -Ur parameter was implemented and activated by default when doing a "make all").

Didn't thought about that. Isn't it strange that the '-Fisrc' option triggers this behavior? Using fpcmake this problem never occurs, even not when the rtl is compiled separately, because there is no '-Fisrc' option passed to the compiler.
Fpmake, as it is now, however, does pass it, so more people will encounter this problem.

Joost.

My Lazarus blog: http://www.lazarussupport.com/lazarus/weblog

Reply by email

Jonas Maebe
to Joost van der Sluis
Joost van der Sluis wrote 18 lines
On Tue, 2011-09-06 at 21:58 +0200, Jonas Maebe wrote: > On 06 Sep 2011, at 21:48, Joost van der Sluis wrote: > >> Can someone reproduce this? And what to do now? I've even did a >> touch on >> the rtl/objpas/parser.inc, but that doesn't help. > > If you perform a top level "make all", the RTL and packages are > compiled with -Ur so that it never gets recompiled. If you compile > them manually, you should add that parameter yourself in most cases > (unless you are debugging a bug regarding include files in the > RTL). This problem is not specific to the RTL vs packages, it can > also happen with any FPC-supplied unit and third party sources > (which is why the -Ur parameter was implemented and activated by > default when doing a "make all"). Didn't thought about that. Isn't it strange that the '-Fisrc' option triggers this behavior?

I guess that explicitly adding a directory to the include path makes the compiler more strict regarding checking for include files in that directory. Maybe that was done before we had -Ur option to avoid at least some problems with include file name conflicts if they were only in the current directory.

Fpmake, as it is now, however, does pass it, so more people will encounter this problem.

Using standard FPC units that were not compiled with -Ur is unsupported in a deployment environment.

Jonas

Reply by email