Hmm, let me extend your example: /project/unit1.pas /project/StrUtils.pas /lib/StrUtils.pas /lib/ExtraUtils.pas
---code--- unit ExtraUtils; uses StrUtils; // assumed library StrUtils, not project ===code=== However, since StrUtils is present in project directory, it will be used instead, causing compilation errors. compiling with fpc -ALIAS /lib/* TheLib won't help, unless you change "ExtraUtils.pas" to use TheLib.StrUtils Your thoughts? My proposal looks like this: -SEARCH fpc -SEARCH/program/unit1.pas@/lib/ Causing fpc to look for units at "Libs" first when compiling "/program/unit1.pas" No changes in any source code necessary. With the swicth present ---code--- unit unit1 uses StrUtils; // strutils from lib ===code=== thanks, Dmitry On Sat, Nov 2, 2013 at 6:55 AM, Marcos Douglas <m...@delfire.net> wrote: > On Fri, Nov 1, 2013 at 11:54 PM, Dmitry Boyarintsev > <skalogryz.li...@gmail.com> wrote: > > Technical problem: > > * a unit name collision of two independent library code. Either library > are > > using unit with the same name. The code in the conflicting units is > > different. Thus one library should use its own unit, the other should use > > its own. > > Since FPC allows to specify the search path for the whole compiled > program, > > the second library used, will be using a wrong unit (from the first > > library), causing either compilation to fail or wrong code generated; > > > > Can anyone think of any logical problems with this feature: > > * allow any unit (or units under specified directories) to use their own > > "unit-search" paths, than defined for the project. In that case if a > library > > has its own unit, the compiler will be using the library specific unit > (by > > finding it in the library specific search path). > > > > From compiler point of view - it's only a matter of where to find the > source > > code for the unit and how to name the resulting objects and object file. > > (names must not conflict, in case some units of a compiler project > match); > > Linker, shouldn't have any issues as long as objects files were created > > properly; > > Debugging information - no problems here, since the source file name is > > specified explicitly and is typically full path; > > > > Limitations: > > * two units with the same name are not allowed to be used by any other > unit > > at the same time > > uses unitA (from pathA), unitA (from pathB) - not allowed; > > * RTTI collisions are not to be resolved by this feature; > > Complex... > > Think this: > /project/unit1.pas > /project/StrUtils.pas > /lib/StrUtils.pas > > ===code=== > unit unit1; > > uses StrUtils; // local or Lib??? > ===code=== > > To compile the unit1.pas the compiler need to know where is > StrUtils.pas and whether to use /lib/StrUtils or /project/StrUtils, > right? > So, if we could to set a parameter to compiler saying: > fpc -ALIAS /lib/* TheLib > > Of course I invented the "-ALIAS" parameter. > So, returning to unit1, if we want to use the "local" StrUtils unit, > just use the name "StrUtils". But if we want to use the Lib's > StrUtils, then: > > ===code=== > unit unit1; > > uses TheLib.StrUtils; > ===code=== > > What do you think? > > Best regards, > Marcos Douglas > _______________________________________________ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal >
_______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
