Open rondiplomatico opened 8 years ago
I think if we can do this using the cache, that is the way to go - definitely the expected behaviour for cmake systems.
I think everything should be in the cache too, people will want to use GUI applications to configure their build.
As a consequence of this should we get rid of the empty(ish) build directory in manage?
By local config files do you mean OpenCMISSLocalConfig.cmake? If so how would the cache get created in the first place and what would be the process for multi config setups? Would the plan be to edit OpenCMISSDefaultConfig.cmake and then invoke cmake in a build directory to create the cache? For a different config then edit the default config and invoke cmake again (in a different build directory)? If this is the case then the naive user has a problem because there are two ways to do the same thing. You tell them to edit a file to set a variable and then you tell them to edit the cache to change the value of the same variable? Whilst editing the cache might be the expected behaviour for more experienced developers I don't think this is the case for novice users. Can't the cache be dependent on the config file and be rebuilt if the config file changes? Then people can do what they want - edit the cache with gui's or change the config file? Although the config file does provide a handy reference to look at to see all the config variables without knowing too much cmake and this would be lost if you edited the cache variables directly.
No I don't think you have the right idea here, the default config doesn't get edited (being the default) it just sets variables that you don't specify to their default values. If you wanted to change a configuration you would then edit the value of a particular variable in a GUI of through the command line. You manage the config from the build directory. 90% of new users to CMake use the GUI to configure the build.
As a matter of fact, the local config files are effectively no longer needed, as we now have separate root build directories (e.g. manage/build, manage/build_intel, etc) and everything could as well be sourced from the cache. i'm raising this as this issue has caused quite some confusion on whether to change cmake settings via the cache or those localconfig files - and the more native cmake way is to use the cache and respective editing tools like ccmake or CMake-GUI. any remarks?
so what needs to be done is to remove the opencmiss localconfig files and instead change the opencmissdefaults.cmake file so that all the settings are being put into the cache instead.