Preprocessor

[pdebuyl]

Will stdlib require a preprocessor? It is mentioned in #13 #35 and #72

I suggest that this is discussed as it impacts the way the code is built and possibly the way users of stdlib will call certain features. Not that I have any definitive opinion on the topic, but as there was a discussion on cmake, compiler support and CI, this seems appropriate also for preprocessing.

[certik]

Yes, it's relevant to how files should be named whether .f90 or .F90, etc. I really don't like the .F90 suffix, as the capital letter signals some old FORTRAN style code. I wish the convention was the other way round, that .f90 gets automatically preprocessed.

It seems the discussion at #35 seems to converge towards trying jin2for, instead of using a preprocessor.

But #72 would need one. Although in my own codes I do not use a preprocessor and just do call assert(...). It does not print the line number, but that could be fixed by printing the whole stacktrace, there are libraries that can do that (although they might not work on all platforms).

Given resistance to standardize a preprocessor in j3-fortran/fortran_proposals#65, I don't know what the best recommended practice is.

[gronki]

Preprocessing can be forced upon by -cpp option in most compilers. I imagine that is compiler dependent though.

I dislike uppercase .F90 too but I still use it in my projects as most compilers recognize this without the need for extra options. So I would imagine that would be the most fail-safe solution.

[certik]

See the discussion in this and following comments: #72 (comment). Where we decided to just use .f90, but pass an appropriate compiler option (such as -fpp) to pre-process the files.

[pdebuyl]

Hi @certik since I opened this issue, it became obvious that stdlib would rely on a preprocessor. I am thus closing the issue.