I seriously hate it when people don't write their inc files future proof!

I seriously hate it when people don't write their inc files future proof!
New Delphi version - boom, stuff does not compile anymore because something like IFDEF SomeAncientDelphiVersion_UP is not true anymore because they only define it for verxxx for every released version.

Or even worse stuff compiles but breaks somewhere.

Argh, use jedi.inc if you are unable to do it yourself properly!
https://github.com/project-jedi/jedi

Comments

  1. Even more so since we've had
    {$if compilerversion >= xxx} since D6.

    ReplyDelete
  2. Tell us their names, we will hate them too :)

    ReplyDelete
  3. I could not agree more!  I've had brand new package for the latest IDE won't compile because the inc files were not correct.   And it seems everyone wants to do their own version/style, sometimes wrong location.   I rely on a lot of third party stuff, and upgrading to the next IDE is so maddening, I take a month to do it so I don't raise my blood pressure too much.

    ReplyDelete
  4. This is correct if you're not using FMX. There is a lot of breaking changes in almost every version, so universal .inc won't help.

    ReplyDelete
  5. Wouldn't jedi.inc suffer from the same problem? {$ifdef ver300} {$define delphi_x_seattle}… How is that future proof?

    ReplyDelete
  6. Ondrej Kelle Check again all places where DELPHIX_SEATTLE is defined in jedi.inc
    The defines are designed in a way that any future version is always treated as the latest known one. So if you use ifdef DelphiXE_Up somewhere and you compile that code in Delphi 10 Timbuktu it will work. The same is the case for all the feature defines. So if you are using SUPPORTS_UNICODE somewhere in your "must also still work for Dephi 5" code it will be defined for future yet unknown Delphi versions.

    ReplyDelete
  7. Stefan Glienke​​ I see now, {$IFDEF UNKNOWN_COMPILER_VERSION}… That's a good idea. Thanks!

    ReplyDelete
  8. Stefan Glienke On the contrary, fixing the .inc is the easiest think, and "may" indicate that the platform is supported, whereas it has not been tested. Everyone can add the conditional check, but you would have to cross fingers if you expect it to work flowlessly... I've seen compatibility problems between versions (e.g. record alignment, DB.pas changes... and it is even worse for UI components, especially with FMX). It is not because it compiles that it works.
    IMHO "future proof" .inc is a good idea in an ideal world, when it should come at least with integrated regression tests.
    A new compiler version should be supported while Delphi is in beta testing change. Then published as beta (or in the trunk for OS projects), ASAP. You should not have to wait weeks for support, nor hack the .inc on your hand. Especially with commercial components.

    ReplyDelete

Post a Comment