[fpc-pascal] Re: [Bulk] Re: Namespaces Support
Dmitry Boyarintsev
skalogryz.lists at gmail.com
Mon Nov 4 02:22:35 CET 2013
On Sun, Nov 3, 2013 at 10:27 AM, Marcos Douglas <md at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20131103/50ab2a0b/attachment.html>
More information about the fpc-pascal
mailing list