In our previous episode, Bart said: > > Note that a bulky "read externally" alternative won't be enabled by default > > in FPC anyway, so it doesn't even alleviate the "need to include clocale" > > issue. The point is if in this case it is worth the trouble if most people > > then > > happily link to X or Lazarus. > > Personally I would like to see the formatsettings being localised by > default (by SysUtils), since on Windows it is (Delphi compatibility) > and I'd expect it ot be the same on all platforms. > For this reason a "bulky read external" alternative might be useful if > we do not want SysUtils be dependent on libc.
It's really doubtful it would be done that way. It just adds a possible reason for breakage to (in practice) each binary. The timezone stuff didn't really make me happy. Since it is only a global (and not per unit) decision, Delphi compatibility doesn't say much, since project-wide information is not Delphi compatible in the first place. A plugin is the more logical route, for the ones that want to remain libc free, but want to risk maintainance problems. > In that case I'd opt for parsing the text-based versions, since the > compiled ones are libc dependent (their format changes). Are they guaranteed default installed on most OSes ? It's pretty hard to parse something that is not there. Also start inventorizing all possible solutions on all possible distro's and OSes. > Anyone who links his app to libc (like a standard Lazarus app) can the > hapilly include clocale (because the text-based parsing might not be > 100% accurate). But has an unneeded size penalty (and breakage, since it is always run!). _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
