[fpc-pascal] uses myunit in '../src/myunit.pas' ?

[Tim Veldhuizen]

On 15 Feb 2017 04:47, Michael Van Canneyt <michael at freepascal.org> wrote:
>
>
>
> On Tue, 14 Feb 2017, fredvs wrote: 
>
> >> Please simply use "{$unitpath }" 
> > 
> > Huh, Mattias present me yesterday a beautiful "{$unitpath }". 
> > 
> > We played together all the night, without any trouble. 
Just because things work now, doesn't mean they always will. Do you make software to "play" and keep yourself busy, or do you want to get to business and do something useful? If the latter option, then i think you'll want to make sure things don't break because of wrong decisions in the past. And i believe you'll want to keep things managable, simple and reusable. These are the principles that form the basis for keeping configuration such as unit search paths out of the source code.

I once restored a backup of my current project to a different directory than it used to be in and had to fix many path references as a result. (Yes even in sourcecode, because my project generates pascal code and calls fpc, so it also generates a -Fu parameter and it used an absolute path because I'm stupid and used an easy quick-fix at the time ;) ) Would you want to do that for every source file you've got?

> > And this morning Matt said that I may not trust in {$unitpath }, that I will 
> > only have problems, that I should think at something else. ;-( 
>
> He is correct. 
And i agree. You're not talking about a bunch of shell scripts here you see. While they are interpreted, units are compiled and some things are included into the object file which means you'd need to recompile the unit in order to use it in a safe, predictable and understandable way. The compiler usually figures out which units need to be recompiled. Configuration is therefore not something you want to put into sourcecode, as this may confuse the compiler. This may result to it not recompiling a unit, which may lead to unpredictable behaviour. That would mean your program does things that the source code cannot explain. Believe me, this is hell, I've been there. (In a project about 10 years ago, a class was being rewritten from scratch. When debugging some weird error, I noticed a variable that "magically" changed value even though it was not assigned anywhere in the source code appart from the initialisation by the constructor. It turned out to be an incorrect static cast to the old class type, in a unit that was not being recompiled so the object (of the new type) was used by that unit as if it was the old type. It cost me three days to debug this nice little beasty and because debug info was not available, i had to trace in assembly even. The cause? Configuration options incorrect. The unit was implicitly linked..)

Greetz,
Tim