<div dir="ltr">On Mon, Nov 4, 2013 at 9:08 AM, Marcos Douglas <span dir="ltr"><<a href="mailto:md@delfire.net" target="_blank">md@delfire.net</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

2- If ExtraUtils depends on StrUtils.pas from "lib". But "otherlib" is<br>
not a subdirectory of lib then the "otherlib needs to be compiled<br>
using a ALIAS:<br>
-ALIAS=TheLib@lib\*<br></blockquote><div>Ah, yes, you've mentioned the necessity for two steps compilation.<br>(compile a package first and then compile the program). <br>Which brings the necessity for external "tools" (similar to make files) or an IDE must be smart enough to handle them.<br>
</div><div>(please note "an IDE", thus not refer erring to Lazarus specifically).<br></div><div><br></div><div>But, it might help solving the problem with object names, since a recompiled package will update object files. hmm.. or not.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
But, for me, doesn't any sense the otherlib does not know the lib's sources.<br></blockquote></div>Otherlib knows about "lib"s sources - it knows that there should be "StrUtils" unit.<br>However, it doesn't know anything about there the "StrUtils" is located, as well as it doesn't care what to do with other files of the project. It's compilers job.<br>
<br></div><div class="gmail_extra">In my turn, this is how I'd suggest to compile it:<br><br>program\unit1.pas (uses lib/StrUtils.pas)<br>program\StrUtils.pas<br>program\unit2.pas (uses program/StrUtils.pas)<br>lib\StrUtils.pas <br>
otherlib\ExtraUtils.pas (uses lib/StrUtils.pas)<br>-- <br></div><div class="gmail_extra">fpc<br></div><div class="gmail_extra">-SEARCH program/unit1.pas lib/StrUtils.pas   (point unit1 to use lib/StrUtils explicitly) <br>
</div><div class="gmail_extra">-SEARCH otherlib/ lib/ (point "otherlib" units to use any unit from "lib" first, if found)<br></div><div class="gmail_extra">-Fulib<br></div><div class="gmail_extra">-Fuotherlib<br>
</div><div class="gmail_extra"></div><div class="gmail_extra">program.pas<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">That's it, compile everything in one call.<br></div><div class="gmail_extra">
<br></div><div class="gmail_extra">However, the problem with object name conflict (if packages are precompiled) doesn't allow this to happen.<br></div><div class="gmail_extra">* using internal linker could help to solve this problem (in that case FPC could whatever it wants)<br>
</div><div class="gmail_extra">* generating object files during the actual compilation could also help this problem (thus "precompile" will only prepare .ppu files with some kind of a code, in some kind of form). During the compilation, the code from .ppu will be transfered to .object files with the names changed to avoid conflicts.<br>
</div><div class="gmail_extra"><br>thanks,<br>Dmitry<br><br><br></div></div>