xsdk-project / xsdkcmakeproj Goto Github PK

Next Action Status:

Waiting for feedback on requirements (i.e. existence and behavior of XSDK_ENABLE_<LANG> when <LANG> is not supported by a CMake project) ...

Description:

It seems that there is a desire for the vars XSDK_ENABLE_<LANG> to be settable by the cleint configuring a CMake project using the XSDKDefaults.cmake module (see TriBITSPub/TriBITS#121 and xiaoyeli/superlu_dist#3).

When XSDKDefaults.cmake module was written, the assumption that was made was that the client CMake project would know what languages it needed and would set them with SET(XSDK_ENABLE_<LANG> [TRUE|FALSE]) before including the module. If you look here, you can see that these vars are set using SET_DEFAULT() which does not create a CMake cache var so these would be invisible to the general user. That seems not to be what people expected so we need to change this; hence TriBITSPub/TriBITS#121.

But what about CMake client projects where a given language is not optional? For example, does it make any sense for a client project to expose XSDK_ENABLE_Fortran as a cache var if Fortran is required in order to build anything? Clearly a client project like Trilinos or SuperLUDist could not build anything if the client disabled C and C++. So how is this handled?

The requirements for the handling of optional language support and languages is not clear to me.

Tasks:

1. Nail down requirements for XSDK_ENABLE_<LANG> for the use cases where the language <LANG> is a) required, b) optional, and c) not supported
   • When <LANG> is required, then XSDK_ENABLE_<LANG> is supported and if the user selects XSDK_ENABLE_<LANG>=OFF, then the configure should error out with a good error message (see below) [Done]
   • When <LANG> is optional, then user can select XSDK_ENABLE_<LANG>=[ON|OFF] [Done]
   • When <LANG> is not even supported: ... ToDo determine behavior (see below) ...
2. Implemented decided on behavior in the XSDKDefaults.cmake module and add macro XSDK_ENABLE_LANGAUGES(). Add automated tests to define and protect this new behavior.
3. Incorporate these changes into TriBITS (TriBITSPub/TriBITS#121) and then snapshot into Trilinos and then make PR for SuperLU and SuperLUDist maint branches.