On Mon, 7 Mar 2016, Marco van de Voort wrote:
In our previous episode, Michael Van Canneyt said:
However in Michael's scheme with Sysutils using Ansi and System.Sysutils
using unicodestring this will fail.
Why would this fail ? All we need to do is introduce -NS ?
If you have a mix of generations (as is currently possible with Delphi), how
do you avoid linking in two different sysutils?
And obviously the 2 RTLs cannot be mixed.
Correct. And if they only differ in name, dotted or not, and you can
set namespaces to override the dots, how do you keep them apart?
We probably agree that trying to mix both approaches (dotted, non-dotted) is a
recipe for disaster.
So, different directories, and different compiler configs must be used,
obviously.
I never had the intention of having all this in 1 directory.
i.e. we distribute
/usr/local/lib/fpc/4.0.0/x86_64-linux/XYZ
/usr/local/lib/fpc/4.0.0/x86_64-linux/dotted/XYZ
But only one is referenced in fpc.cfg :
#IFDEF NAMESPACED
/usr/local/lib/fpc/4.0.0/x86_64-linux/dotted/XYZ
#ELSE
/usr/local/lib/fpc/4.0.0/x86_64-linux/XYZ
#ENDIF
where the -NS switch defines NAMESPACED
(or whatever)
Worse, one mistake in your sources (e.g. a non qualified forms) and you get
bunches of "Incompatible Type Forms.TForm, expected VCL.Forms.TForm" style
errors.
I think some solution with alternative -Fu settings is to be prefered and
not abuse an unrelated feature (dotted unitnames) to have both ansi an
unicodestrings in one install.
The alternative is 4 rtls.
Dotted, ansi
not dotted, ansi
Dotted, unicode
not dotted, unicode.
which is clear nonsense.
No, two rtls, both dotted, with namespace if needed. Which is the same as
what you propose, just kept physically apart.
If the above fails to satisfy you, no problem, all for it.
But I don't see the use of the dotted for old code.
Lets not forget that Delphi tries to hide a lot of the complexity by always
writing a complete config file and using that file when compiling.
I don't see why we cannot do the same.
Michael.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
