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; thanks, Dmitry On Wed, Oct 30, 2013 at 4:38 PM, Dmitry Boyarintsev < skalogryz.li...@gmail.com> wrote: > On Wed, Oct 30, 2013 at 3:45 PM, Marco van de Voort <mar...@stack.nl>wrote: > >> What if unitaa needs recompilation, and it is not in the dir it was >> originally >> compiled in. .\some\other\place then has a different meaning. >> >> Specially if the relative paths are short (like ..\src\ or so), there is >> still >> quite some room for clashes. >> >> That is probably the reason it is mainly used in the DPR, there relative >> paths can be interpreted relative to the .dpr, and .dpr's are generally >> not >> recompiled in other directories. >> > > Definitely, that's not the way to go. Since a unit source can rarely be > adequate to the compilation environment. > > thanks, > Dmitry >
_______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
