Issue #1 wontfix

dummy modules for extdouble and quadruple

jas43
created an issue

I was caught out by the fact that I should now only compile some of the source files for extdouble and quadruple (depending on whether I want those features or not). It's slightly inconvenient for simple build systems.

Is there anything wrong with using C preprocessing to obtain the same effect? For example, aot_extdouble_top_module.F90 instead of aot_extdouble_top_module.f90 and dummy_aot_extdouble_top_module.f90:

module aot_extdouble_top_module

  implicit none

  private

  integer, parameter :: xdble_k = selected_real_kind(18)

#ifdef EXTDOUBLE

  ! main body of aot_extdouble_top_module.f90

#endif

end module aot_extdouble_top_module

Thoughts/comments?

Thanks!

Comments (6)

  1. Harald Klimach repo owner

    We are using coco in our other projects for preprocessing, but I didn't want to introduce this build-dependency into Aotus. I wanted to avoid the preprocessing with CPP as not all compilers support it, and I am unsure about its interaction with Doxygen. Thus I would anyway call CPP before actually compiling the code, which counters the goal to avoid an additional build dependency. Thus the pre-processing solution using waf itself.

    If this is too inconvenient and causing problems, I'd rather consider to introduce coco also in Aotus, as it would also simplify all those code parts which are simply duplicated for different data types. What would your opinion be on the CoCo solution? It is a single Fortran 90 program available under the GPL.

  2. jas43 reporter

    Ok. Don't worry: I'd rather not introduce a dependency on coco. I am happy just to include only the dummy modules in my projects unless I really need the extdouble or quadruple support--a much simpler solution than worrying with preprocessing!

  3. Log in to comment