[fpc-devel]Incomatibility: Include files directory ordering

[Konstantin Münning]

Am Fre, 2003-04-11 um 13.31 schrieb Peter Vreman:
> > Hello everybody!
> >
> > For some time now I have noticed a small incompatibility between FPC and
> > BP(7) about the loading of include files. I am currently using FPC 1.0.4
> > so if this is already resolved in a more recent version please drop me a
> > note and excuse me bothering you with that.
> >
> > This different behaviour leads for me to a slight inconvenience, so I
> > could live with it, but is different to BP7 and as FPC tries to be fully
> > compatible this may be of interest.
> >
> > It is about the ordering of the include files directories. In BP the
> > current directory is searched first, probably next is the directory
> > where the compiled file is located (I haven't verified this so please
> > check if you want to be shure, may be this has to be given explicitly)
> > and then the specified additional directories are checked. In FPC the
> > directory where the compiled file is located is checked ALLWAYS FIRST, I
> > have found no switch or option to change this and this makes me some
> > trouble now.
> >
> > But besides that, from the logical view the BP approach seems to be
> > better - if you use an include file for some settings (compiler defines,
> > variables etc.) and compile your project in a different directory than
> > some common used files (e.g. Units), the units may be compiled with
> > wrong settings (as long as local files are present at the units
> > location, let's say for test purpose when these units were originally
> > written).
> >
> > I don't know if maybe now someone depends on the new include directory
> > ordering which would be broken if this is reverted to the BP scheme, but
> > at least a compiler flag may be introduced (or to be implicitly in -So
> > which for 1.0.4 is not).
> >
> > From historical view, I had noticed that at some 0.9x release of FPC but
> > at this point it was not important. Now when I try to migrate my
> > projects to FPC this difference is noticed well.
> 
> FPC is compatible with Delphi/Kylix. I don't have tp7 installed here to
> test. But the test i did was:
> 
> ./p.inc
> writeln('hallo');
> 
> ./pp/p.pp
> begin
>   {$i p.inc}
> end.
> 
> ./pp/p.inc
> writeln('hello');
> 
> And then compile ./pp/p.pp, the output of the generated executable was
> 'hello'

Was this test with fpc? Then this confirms what I have noticed. Or have
you tested this with Delphi/Kylix? Then they seem to have changed it.
Maybe without noticing ;-).

> IMHO is not good to make differences in behaviour in which order FPC will
> find files. The -S is for Syntax/Semantics within the sources and not how
> and where it will find files.

You are right, if fpc tries to be fully Delphi/Kylix compatible then
their search behaviour should be the same. Even if I see no good in this
kind of ordering. (Can someone explain me why he would prefer this
search order from the one I need?)

Is there a way for the current release to make the compiler search the
current directory first (except compiling my own of course ;-))? The -Fi
(-I) flag only appends a directory and I haven't found any other.

For the future, it would be nice to have a switch for this compatibility
or at least a switch to add directories at the beginning of the search
list (I can't remember on what compiler I have seen such a switch but
there was one). Otherwise I have no idea how to make my bigger projects
coexist with BP and FPC... :-(

Thanks and have a nice day,
-- 
Konstantin Münning              ,,,
-------------------------------/'^'\------------------------------------
www.muenning.com              ( o o )                  koko at muenning.com
--------------------------oOOO--(_)--OOOo-------------------------------
            Beware of Programmers who carry screwdrivers.
                                    -- Leonard Brandwein
                               (-O-)
The man who follows the crowd will usually get no further than the
crowd.
The man who walks alone is likely to find himself in places no one has
ever been.                          -- Alan Ashley-Pitt