On 2020/09/24 11:04, Sven Barth via lazarus wrote:
Bo Berglund via lazarus <lazarus@lists.lazarus-ide.org
<mailto:lazarus@lists.lazarus-ide.org>> schrieb am Do., 24. Sep. 2020,
08:08:
>If course there is. That's how the unit system is supposed to
work after
>all.
>
Yes, I realize that now.
It means that the client even though it will not interface to the
hardware will have all of the code used to do that included in the
app, right?
The compiler (and linker) only includes code that is used. Thus as
long as you don't call the hardware functions anywhere in your program
(this includes indirectly or through initialization/finalization
sections) then the code won't be in the final binary either.
Regards,
Sven
Sven, I believe Bo's problem is that even though he won't need the Code
(which the linker/compiler will surely cleverly disregard), he also do
not even wish to "need" the physical Unit files to be in view of the
compiler - at least not the secondary-dependency units - when he
references a unit file in which he only needs a few declarations visible.
Sadly Bo, the entire premise of the Unit system is that every dependency
will be in view, the compiler cannot decide BEFORE compiling that it
would or wouldn't need a unit which appears in a "unit" clause lower
down the dependency tree. Consider that a used unit may well declare a
global variable that overrides one from a higher-up unit, for instance.
So even though the program has all the participating symbols at hand
without looking at this depended unit with the override, it will produce
a different program (than when that override IS considered) and so
cannot simply decide to ignore/not require a unit preemptively before
actually parsing the physical file.
All units you use, pluse every dependent unit they use, must be
available and visible to the compiler. That rule is absolute.
--
_______________________________________________
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
