[fpc-devel] The (near) future of strings

[Michael Van Canneyt]

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.