On Sun, Nov 3, 2013 at 10:27 AM, Marcos Douglas <m...@delfire.net> wrote:
> Wrong. Do not breaks the compiler backward compatibility. > I said " in the same directory and/or own tree", ie, in the same > directory and subdirectories. For these cases, the compiler do not > need changes. > The compiler doesn't use a unit's same directory for searching units. It is using project's file directory for searching and then any directories referenced is -Fu switch. Thus the same list of search directories is used for any unit in the project (and that's causing the requirement to have all unit names unique per project) First, if you have a lib that have dependencies to another lib, you > have to provide all sources together -- in the same directory or > subdirectories. For this case just use the rule #1. > But, if you did not provide the sources for the other lib, the user > will need to define the "ALIAS" to the lib that have dependencies > before compile it (package). For this case use the rule #2. > Changing the structure of a project is a big NO. For a number of reasons: * a compiler change should never force a developer to make any major changes in the project sources or structure; * it might be impossible to merge two different components into the same directory or sub directory, because of the conflicting file names; * the external tools (i.e. SVN) might require two components be in a separate folders (i.e. for syncing sources); -so I'd removing rule #1 as a solution here. As well as rule #2, since it's not an option to change 3d party code (even just to introduce an alias reference). Don't forget that you've mentioned it earlier yourself. thanks, Dmitry
_______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal