Tired of setting common application settings zillion times for each compiler/release variant?

-
Tired of setting common application settings zillion times for each compiler/release variant?

Please vote for:

Combine common application settings based on OS platform
https://quality.embarcadero.com/browse/RSP-20883
https://quality.embarcadero.com/browse/RSP-20883

Comments

  1. Achim KalwaJuly 16, 2018 at 4:26 AM

    Voted.

    ReplyDelete
  2. Paul TOTHJuly 16, 2018 at 10:02 AM

    new dproj bugs in perspective...

    putting everything in the source code with compiler directives is the best option for me

    {$IFDEF MSWINDOW}
    {$MAINICON 'Main.ico'} // can be done with a .RC file
    {$ENDIF}

    {$IFDEF ANDROID}
    {$PERMISSION READ_EXTERNAL_STORAGE}
    {$ENDIF}

    ReplyDelete
  3. Job EspejelJuly 16, 2018 at 10:11 AM

    voted

    ReplyDelete
  4. Dalija PrasnikarJuly 16, 2018 at 10:36 AM

    Paul TOTH I am not sure I fully like the idea of compiler directives :)

    On one hand that would be better than current nightmare, but if you go that far in replacing current @#$%&!? dproj file then I would more prefer splitting that monster into separate files for each OS platform.

    ReplyDelete
  5. Dalija PrasnikarJuly 16, 2018 at 10:38 AM

    Another issue this feature request does not cover is the fact dproj file is not VCS friendly. Not only it changes randomly every time you open the project and compile it, it also stores workspace and developer based information that does not belong to VCS in the first place.

    ReplyDelete
  6. Achim KalwaJuly 16, 2018 at 10:41 AM

    Dalija Prasnikar As a workaround, you may use Uwe Raabe's Project Magician:

    https://www.uweraabe.de/Blog/2018/05/17/keep-your-project-files-clean-with-project-magician/
    uweraabe.de - Keep Your Project Files Clean With Project Magician | The Art of Delphi Programming

    ReplyDelete
  7. Dalija PrasnikarJuly 16, 2018 at 11:04 AM

    Achim Kalwa Thanks, I don't know how I managed to miss that :)

    ReplyDelete
  8. Dalija PrasnikarJuly 16, 2018 at 11:15 AM

    IDE plugins to the rescue :)

    On one hand it is great to have such plugins and devoted developers that fix and improve the IDE experience. On other, it is sad that almost basic things don't work out of the box and we have to install various plugins to have functional IDE.

    Old Delphi users might be used to that. But if Delphi want's to grow, all those little things need to be polished and working. Over the years Project Options has grown into a particularly nasty nightmare.

    ReplyDelete
  9. Paul TOTHJuly 16, 2018 at 11:50 AM

    Dalija Prasnikar you can split compiler directive easly
    {$IFDEF MSWINDOWS}
    {$INCLUDE WindowsSettings.inc}
    {$ENDIF}
    {$IFDEF ANDROID}
    {$INCLUDE MobileCommonSettings.inc}
    {$INCLIDE AndroidSettings.inc}
    {$ENDIF}

    the only drawback is the poor ability of the IDE to handle included files.

    ReplyDelete
  10. Dalija PrasnikarJuly 16, 2018 at 12:14 PM

    Paul TOTH Splitting is not the problem... what I don't like would be new compiler directives to support all needed options - like $PERMISSION. That would require updating the parser.

    Tweaking Project Options to support single settings per platform for common Application settings and Version is much easier. Dproj file format does not need to change for that improvement.

    ReplyDelete
  11. Alexander ElaginJuly 17, 2018 at 12:33 AM

    How about this (conceptually similar to UniDAC's provider-specific options):
    {$OPTION 'Android.Permission=READ_EXTERNAL_STORAGE'}
    {$OPTION 'Windows.Icon=MAINICON.ICO'}
    {$OPTION 'Icon=MAINICON.ICO'} // short form for current config
    etc.
    Requires only one directive parser, fully extendable.

    ReplyDelete
  12. Uwe RaabeJuly 17, 2018 at 1:07 AM

    I am pretty sure this directive approach is not going to work, because the current build configuration with all its inheritance is used as an object inside the IDE and its plugins. Resembling this structure from the source with IFDEFs looks like a real nightmare to me. Thus I would object massively against every feature request in this direction.
    Actually we already have several such cases like with the LIBSUFFIX setting, which is in the dproj file as well as in the dpr file. Switching between configurations should always update the dpr, but currently it doesn't always do so. I would prefer when these settings are set during the build via command line or config file. Having these in the dpr combined with different settings per build configuration is a real PITA.
    I really like having these build and platform settings separate from the sources. Given the aversion of the IDE against conditional defines in the dpr the above suggestions may produce more harm than they are supposed to cure.
    See: LIBVERSION/LIBSUFFIX/LIBPREFIX Can be specified by Config but break the Build when defined multiple times

    https://quality.embarcadero.com/browse/RSP-15824

    ReplyDelete

Post a Comment