Default Values for Configuration Options

[hsorby]

This issue is for determining what the default values for the configuration options should be, here are the current options that can be configured along with their current default value:

LIBCELLML_UNIT_TESTS: ON
LIBCELLML_TREAT_WARNINGS_AS_ERRORS: OFF
LIBCELLML_BUILD_TYPE: Release
LIBCELLML_INSTALL_PREFIX: ${CMAKE_INSTALL_PREFIX}
LIBCELLML_BUILD_SHARED: OFF

[only available with gnu compilers]
LIBCELLML_COVERAGE: OFF
LIBCELLML_MEMCHECK: OFF

[agarny]

Just a couple of comments:

• Is it standard practice to build a static library by default rather than a shared library?
• I agree with LIBCELLML_UNIT_TESTS being ON by default, but then shouldn't LIBCELLML_COVERAGE and LIBCELLML_MEMCHECK also be ON by default? Or, can it not be done for some technical reason or another (I seem to vaguely remember something about that)?

[nickerso]

My preferences for the defaults I would use:

LIBCELLML_UNIT_TESTS: ON
LIBCELLML_TREAT_WARNINGS_AS_ERRORS: ON
LIBCELLML_BUILD_TYPE: Debug
LIBCELLML_INSTALL_PREFIX: ${CMAKE_INSTALL_PREFIX}
LIBCELLML_BUILD_SHARED: ON

[agarny]

I imagine the defaults should be suitable for most people? If so, shouldn't those defaults result in a build that can directly be used in a CellML-capable tool? In other words, a release build, as opposed to a debug build. As a consequence, I would have warnings as errors turned off by default (but definitely on for continuous integration). For the tests, I guess it's always nice to have them on by default, even when building a release version of libCellML. Finally, my preference (thinking of OpenCOR here), I would also have LIBCELLML_BUILD_SHARED on by default.

[hsorby]

For me the choice is for who the default build is for:

• library developers
• library users

For library developers you have the settings as @nickerso suggested, for library users I would set the defaults as @agarny suggests

[hsorby]

If we are voting on the default settings I vote for:

library developers

[hsorby]

Maybe we have two flags DEV_SETTINGS and USER_SETTINGS that set these values for us in bulk, but that is an aside.

[agarny]

I guess it's pretty obvious that I would personally vote for library users.

(Not sure about DEV_SETTINGS and USER_SETTINGS. What would happen if, for some reason or another, someone wanted a mix of the two settings?)

[nickerso]

My initial thought is to go with library developers for now and switch the default settings over to something more suitable for library users once we have some code that people want to use. However, I don't have a strong preference as it is trivial to set my own build settings :) so happy to go with either...although if I get the casting vote I go for library developers.

[mirams]

Perhaps we could make the master branch (or release tags) have 'release' optimised builds etc., and then keep the one in development branch on developer settings? (somehow?!)

[agarny]

+1 on @mirams' idea.

[jonc125]

+1 for @mirams again. We do something similar in Chaste as well.

[nickerso]

sounds good - I'm sure Hugh can get the buildbot to set the default values appropriate when it makes the releases.

[hsorby]

Yes, we can make Buildbot implement @mirams idea as part of the release process. (Which will be documented when we go through the release process for the first time)

DEV_SETTINGS and USER_SETTINGS would only be convenience options for bulk setting of options, it wouldn't stop you from changing them to something else the next time you configure the build. Just a thought, but I think we should park that idea for another issue.

[mirams]

The Chaste team calls ideas like this _Prasmagining_ (thinking of things that you can imagine happening and being nice, but having no idea how to implement yourself) in honour of its main proponent @praspath.

[nickerso]

fixed in #16