Make XSDK_ENABLE_<LANG> a user cache var?

[bartlettroscoe]

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 (Make TriBITS senstivie to XSDK_ENABLE_<LANG> instead of just setting it based on ${PROJECT_NAME}_ENABLE_<LANG> TriBITSPub/TriBITS#121) and then snapshot into Trilinos and then make PR for SuperLU and SuperLUDist maint branches.

[BarrySmith]

Optional languages are extremely common, especially Fortran. I could care less about the convoluted design of cmake or tribits; you need to support turning off/on optional languages with a simple option.

[bartlettroscoe]

Optional languages are extremely common, especially Fortran. I could care less about the convoluted design of cmake or tribits; you need to support turning off/on optional languages with a simple option.

It is not an issue of design so much as an issue of requirements. Does it make any sense for a CMake project (or an autotools project or a project using home-grown Python configure script for that matter) to provide a user option for optional language support if the language is required or not even supported? That is the issue. For example, would it make any sense for the PETSc Python configure to support the option --enable-c=0? I mean, if you don't have a working C compiler, then what are you going to get out of PETSc? Likewise, does it make any sense for SuperLU to support a user option for disabling C or for Trilinos to support an option disabling C++? I would say no, but that is exactly what would happen if you just made the variables XSDK_ENABLE_<LANG> CMake cache variables.

So what are the answers to the following questions?

1. If the client CMake project (e.g. SuperLUDist or Trilinos) requires the language <LANG>, should it publish a user CMake cache variable XSDK_ENABLE_<LANG> that a user could set to OFF? If so, what should happen if the user passes in XSDK_ENABLE_<LANG>=OFF?
2. If the client CMake project has no source or testing code whatsoever for the language <LANG>, should it publish a user CMake cache variable XSDK_ENABLE_<LANG>? If so, what should happen if the user passes in XSDK_ENABLE_<LANG>=ON?

Those are requirements not design or implementation details and has nothing to do with CMake or TriBITS at all.

[BarrySmith]

It seems obvious to me. There are required languages that cannot be turned off optional languages that can be turned off, and irelevant languages. Different packages will have different required languages, different optional languages and different irrelevant languages.

Autoconf has --enable- and --disable- For PETSc if you pass in --disable-c it will print a very useful error message. If you pass in --enable-COBOL it will be ignored.

[bartlettroscoe]

Autoconf has --enable- and --disable- For PETSc if you pass in --disable-c it will print a very useful error message.

So PETSc configure will error out right away if the user passes in --disable-c? I did not realize that. That was not obvious to me. If that is the desired behavior, then we can implement that behavior.

If you pass in --enable-COBOL it will be ignored.

Right. The same would happen with CMake as well, but at least CMake would warn the user that they set an a user cache variable that was ignored (which is a warning that you selected a nonsense option or misspelled an option name). What does PETSc configure do if the user passes in a misspelled option name? Does it just silently ignore it, like autotools configure scripts do (if my memory serves back to the Trilinos autotools days)?

[BarrySmith]

$ ./configure --disable-cc

         Configuring PETSc to compile on your system                       

TESTING: checkCCompiler from config.setCompilers(config/BuildSystem/config/setCompilers.py:553) *******************************************************************************

UNABLE to CONFIGURE with GIVEN OPTIONS (see configure.log for details):

A functional C compiler is necessary for configure, cannot use --with-cc=0

---

We don't list unused options at the end, but it could be easily added. You could propose adding that to the xSDK standards and I won't have a rational reason to object.

[bartlettroscoe]

A functional C compiler is necessary for configure, cannot use --with-cc=0

Nice!

Okay, so, if a CMake project requires language <LANG>, then it should support the option XSDK_ENABLE_<LANG> (with the default ON) but if the user sets this to OFF, then INCLUDE(XSDKDefault.cmake) will immediately error out.

But what if a CMake project does not support a known language like C++ or Fortran at all? What should happen then? Should it recognise the option XSDK_ENABLE_<LANG> (which defaults to OFF), and if so, what should happen if the user sets XSDK_ENABLE_<LANG>=ON? Here, again, I am talking about the main languages C, C++, and Fortran and not languages that no one uses for CSE codes like COBOL.

You could propose adding that to the xSDK standards and I won't have a rational reason to object.

I think users would appreciate that. It certainly helped a lot for Trilinos after we paid Kitware to add that feature to CMake. It is especially bad with CMake because CMake cache variables are case sensitive. But since Kitware expected all users to use ccmake or the QT GUI, then never thought this was an issue (but given the problems with cache var mechanism in CMake, that was just not realistic, in my opinion).

[bartlettroscoe]

But what if a CMake project does not support a known language like C++ or Fortran at all? What should happen then? Should it recognise the option XSDK_ENABLE_<LANG> (which defaults to OFF), and if so, what should happen if the user sets XSDK_ENABLE_<LANG>=ON?

What should be the behavior? Here are the options (please vote for one):

1. The option XSDK_ENABLE_<LANG> should not even be defined. In which case, if a user set XSDK_ENABLE_<LANG>=ON, then it would show up as an unknown CMake variable.

2. Define the option XSDK_ENABLE_<LANG> so that if the user sets XSDK_ENABLE_<LANG>=ON then it will not show up as an unknown variable but then do either one of the following:

   a. Silently ignore XSDK_ENABLE_<LANG>=ON

   b. Print a NOTE that the language <LANG> is not used by the given CMake project and therefore setting XSDK_ENABLE_<LANG>=ON has no effect.

So will it be '1', '2.a' or '2.b'?

Again, these are requirements, not design or implementation details.

[ibaned]

From the perspective of a high-level system trying to build all the packages, it would certainly be convenient to be able to set XSDK_ENABLE_<LANG>=ON for all known languages on all packages, without checking whether the package has code in that language. It should be able to do this and still get "clean" CMake output, in case it is looking for trouble in the CMake output. From the perspective of a user trying to keep a minimal configure script, it is perhaps useful to be told that the option is pointless. I vote for '2.b', where NOTE cannot be misinterpreted as a warning or anything else going truly wrong with configuration.

In some sense a package without Fortan code does trivially comply with XSDK_ENABLE_Fortran=ON, i.e. it is compiling all the lines of Fortran code it has in it, which happens to be zero.

[bartlettroscoe]

'2.b', where NOTE cannot be misinterpreted as a warning or anything else going truly wrong with configuration

Excellent! Then that is what we will do.