I'm guessing based on the file names in the units/rtl folder you haven't yet namespaced your RTL units in FPC?
How can we tell FPC that System.* should alias to units without System namespace?
Or is there a different RTL I should be pointing to that is already namespaced to match Delphi?
If I were to take on the effort of renaming RTL units to their namespace, would that be a welcome PR for the team?
Or is there no interest in Delphi namespace compatibility?
It won't be fully compatible anyway. E.g. unit Contnrs might just as well be placed in FCL.Contnrs instead of System.Contnrs (I'm not saying that it will be, but it's at least a possibility). And the LCL units on the other hand will very likely use LCL as prefix instead of VCL.
I simply work the other way, I enter the skip namespace tag in Delphi, and rename all my units on that side.
It won't be fully compatible anyway. E.g. unit Contnrs might just as well be placed in FCL.Contnrs instead of System.Contnrs (I'm not saying that it will be, but it's at least a possibility). And the LCL units on the other hand will very likely use LCL as prefix instead of VCL.
I'm not expecting VCL.* to be compatible with LCL.* lol.I do not see it as a problem if some ifdefs or macros can jump in and help. It might even be that at the end most of the work is already done and transparent for you. There will never be a 100% compatibility, especially when FPC has to support embedded targets like AVR and run on old ones like DOS. But the expectation to be able to write code that compiles on both Delphi and FPC with little effort remains.
But like units in the RTL should be namespaced to match with Delphi imo.
It sounds like you disagree. It's been that sentiment that has kept me from fpc for so long.
However, for example, you can use "System.Delete()" to execute a procedure if you already have a "Delete()" procedure in your application. It's a little namespace.
System is also the name of the always-there unit. This has worked since turbo pascal times.
It won't be fully compatible anyway. E.g. unit Contnrs might just as well be placed in FCL.Contnrs instead of System.Contnrs (I'm not saying that it will be, but it's at least a possibility). And the LCL units on the other hand will very likely use LCL as prefix instead of VCL.
I surely hope not ;)
However, for example, you can use "System.Delete()" to execute a procedure if you already have a "Delete()" procedure in your application. It's a little namespace.
I'd suggest that any departure from this which breaks compatibility with older FPC versions would be a very bad idea.
If we had to vote between keeping FPC compatible with both itself and older versions of Delphi, versus breaking compatibility in the name of chasing enhancements added to Delphi in its dotage, I'd be firmly on the side of tradition.
Once units are namespaced (and assuming that their base name stays the same) you can simply use the already existing -FN option to define default namespaces. E.g. -FNSystem with a unit Classes will lead to the compiler looking for both System.Classes and Classes. So you can keep the source the same, but just adjust the compilation parameters.
Could the introduction of namespaces mess up this convention?
Could the introduction of namespaces mess up this convention?
Why should it? We're talking about introducing namespaces for the RTL, FCL, LCL units, not your own. And the mechanisms for these are already in place since 3.0.0 (namespace support itself) and 3.2.0 (the -FN-parameter).
I'd be interested in the opposite, a tool to strip namespaces from delphi units.I have one. It is simple but not complete: does not parse defines inside the uses clause, does not parse implementation yet and is single file.
So you expect third party providers to cater to both, those that want to use namespaces and those who don't? Also units are provided precompiled in the installers on purpose cause one doesn't have to fiddle with building FPC oneself. Also someone would need to maintain that mechanism.
There's no sense in making things more complicated than they are.
I guess maybe I'll need to provide my own distro then lol.
No ifdef, just remove all namespaces in the source, and then set the default namespace in the delphi IDE to compensate that, and presto it works on both.
No ifdef, just remove all namespaces in the source, and then set the default namespace in the delphi IDE to compensate that, and presto it works on both.
Not so easy. VCl and FMX have sense on delphi. And i prefer to not lose delphi compatibility.
For me FMX never made sense on Delphi.
For me FMX never made sense on Delphi.
For you? I don't know which to say to this.