Allow single and double precision libraries in a single build.

[marsdeno]

Behaviour controlled by ENABLE_SINGLE_PRECISION and ENABLE_DOUBLE_PRECISION.

[FussyDuck]

All committers have signed the CLA.

[wdeconinck]

In principle OK, but I did not think this was needed. What's the rationale?

[wdeconinck]

Regardless of my previous comment if we should even do this, and assuming we do:

We have following lines in the CMakelists.txt

get_filename_component( ecwam-source_dir ${CMAKE_CURRENT_SOURCE_DIR} NAME )
if( ecwam-source_dir MATCHES "ecwam_(dp|sp)" )
  set( ECWAM_PROJECT_NAME ${ecwam-source_dir} )
endif()

For backwards compatibility perhaps there we should make sure that if the ecwam-source_dir is "ecwam_dp" it is only enabling double precision, and if it is "ecwam_sp" it should only enable single precision.

The target names currently set to ${ecwam}_${prec} could in this case also be wrongly named as ecwam_dp_dp and ecwam_sp_sp and the logic needs to be adapted. The value of ${ecwam} is set in line 9 of src/ecwam/CMakeLists.txt

[marsdeno]

I don't think it is needed at the moment, but it would be a step towards allowing both single and double precision libraries to be linked in a single binary, for example OOPS with single precision trajectory and double precision inner loops.

[wdeconinck]

I don't think it is needed at the moment, but it would be a step towards allowing both single and double precision libraries to be linked in a single binary, for example OOPS with single precision trajectory and double precision inner loops.

This will then need to go the ectrans route of trying to make the symbols unique.

[awnawab]

I thought this was needed for easybuild recipes, where we don't want to do the symlinked projects like we do in the bundle but still wish to retain the ability to build both sp and dp targets in a single "bundle" invocation.

In that case, the work of making the symbols unique like in ecTrans could be done in a follow-up PR?

In terms of getting the current PR over the line, we would need a few fixes (which I am happy to help with @marsdeno if you are pressed for time):

• Only build program targets if HAVE_${prec}
• Rework bundle logic now that we are not building one precision at a time
• Rework testing setup now that we are not building one precision at a time

[wdeconinck]

In that case, the work of making the symbols unique like in ecTrans could be done in a follow-up PR?

Yes a separate PR for sure. We should aim to be backwards compatible still for the time being, i.e. not introducing API changes or ABI changes.