Delphi XE2 option set nested limit?

1
votes

I have a complex project group that has about 10 "final" build configurations configured in a tree, where each node has its own option set. Something like this:

  • Base
    • Release
      • Release Generic 1
        • Release Final 1
        • ...
        • Release final 5
      • Release Generic 2
        • Release Final 6
        • ...
    • Debug
      • same as release, but for debug

so, all base, Release, Release Generic X, Release Final Y have their own option set saved in files and added as reference. So you will have

  • base.optset
    • Release.optset
      • Release Generic 1.optset
        • Release Final 1.optset
        • ..

The main differences between these option sets are various compiler defines enabling/disabling certain features that are organized in the tree mentioned above (hence the build targets and the option sets) and obviously search paths that include the needed stuff. So each option set also contains different search paths that depend on the respective build configuration. There are over 100 projects in the project group and most of them relate to one another on different level of configurations, so there are also a bunch of Build Groups, but this is irrelevant for the question as right now I'm trying to build the projects one at a time.

The problem is that every option set is configuring the search path. Up to and including "Release Generic 1.optset" the search path is correctly updated and used. However, the "Release Final 1" and siblings don't get the search paths introduced by "Release Final 1.optset". (I know this because I looked at the compiler messages and checked the parameters passed to dcc32) It appears like the option set is ignored.

Everything is configured with "inherit=true" in the option set.

There is nothing specific in the build configurations, nowhere. Every project uses the configuration in the IDE and option set files only.

Is this issue/limitation documented anywhere/known about? Is there a workaround? Other than applying the option set as value and not by reference.

Thanks.

later edit: I decided to implement a pretty ugly workaround in order to get moving: basically, replicate teh configuration from "Release Generic 1.optset" into each "Release Final ?.optset" this has the major disadvantage of having to edit 5 option set files propagating the same modification, when in need of adding something to "Release Generic 1.optset"

1
delphimsbuilddelphi-xe2
Does this still occur if you specify your build configuration explicity using the MSBUILD command line tool? – LaKraven
@LaKraven opening up a cmd window and calling: rsvars.bat then issuing: msbuild /t:Compile /p:Configuration=Release-Final-1 has the exact same behavior. I noticed something extra this time as I set a conditional define in one of the option set files, so now all the option set files set both at least one search path and at least one conditional define. With this, the command line does not get the search path from the last option set, as described in the question, but it does get an extra DEBUG conditional define after the one set by the Debug configuration ... – ciuly
In the IDE however, everything looks fine. The search paths and the conditional defines. So it might be a msbuild issue after all. – ciuly
This was the purpose of my suggestion to test with MSBUILD! I concur that this appears to be an MSBUILD issue (or a Delphi Compiler issue perhaps), rather than an IDE problem! That, at least, is a step in the right direction! – LaKraven

1 Answers

1
votes

Finally I managed to figure out the problem. It's actually a bug in the Delphi IDE in that it messes up the imports in the dproj file.

Specifically, if an optionset is added once, it will not be maintained with the necessary import condition for the rest of the configs.

This usually happens when you add/delete a configuration, the dproj gets busted and optset files no longer get imported for all the configs.

But once your configs are stable and you no longer change them, the dproj remains stable.

I mocked up an application to validate dproj files against these issues, verifying that each config has its optset files in an import directive. I'm yet to make it auto-correct this, as I'm rather busy. But once I manage to find the time, or if there are more people affected by it and require an automatic fix, I'll try to make a release.

Until then, if you noticed the option set is not applied for a specific config, simply find the configs id in dproj (something like Cfg_10 ) and see if you can find an 

<Import Condition="'$(Cfg_10)'!='' And Exists('optset file path name')" Project="optio file path name"/>

if not, then add it after the other <import calls