Some thoughts and clarifications …
I asked about the paper and I cannot distribute it even though it is still available; but a new version today would be considerably different, emphasizing templating and conditional compilation of various parallel-related methods and how to minimize preprocessing in regards to those aspects of coding – and when abstracting the parallel methods is preferred instead.
CRAY was the only one supporting F-/Coarrays at the time and GPUs were almost exclusively accessed via boutique languages then so it needed an update anyway.
prep(1) was not intended as a replacement for fypp which did not exist when the ancestors of prep(1) such as ufpp(1) were created, but as a Fortran-based and Fortran-targeted tool, which has been lacking in general for decades (accept that COCO was implemented in Fortran). I need a preprocessor with the longevity and portability of Fortran that is maintainable by Fortran-centric programmers, and to me that means it is a major plus if it is written in Fortran.
I hope that fpm(1) in particular can support user-specified pre-processing agnostically as is possible with make(1); and that prep(1) would be a good preprocessor solution for a good part of the community, as it is for me. It has proven to be very portable and easily built in any Fortran environment, including a nearly exclusively-Fortran environment.
I would like to see a method evolve in fpm(1) like I described where pre-processing is treated somewhat like compiling in that the post-processed files are created in the build/ directory and then compiled from there, continuing on the theme in fpm that output files are removed from the user directory and can exist for each custom build simultaneously.
In my own build environment ( which now coexists with fpm in everything I have managed to extract into a github repository) only the prep(1) files exist in the source directories and all source files requiring preprocessing create output in a scratch directory which is then compiled and placed into an ar(1)-build library so no .f90 or .o files exist afterward. This is much cleaner and allows for concurrent builds compared to a typical make(1) build; so I would really like to see fpm(1) continue on a somewhat similar path. make(1) (even before gmake) actually supports libraries in such a way that a conditional rebuild can be triggered from the entry in the libXXX.a file instead of the “.o” file, and by including compiler-specific make files can support multiple compilers relatively elegantly but it sure was not obvious to me how to do that at first years ago; but fpm(1) does much the same with option-and-compiler-specific build/ subdirectories; so I really like that.
Neither fpp/cpp nor fypp quite fits my needs and I have several million lines of code that depends on a prep-like preprocessor primarily to allow for documentation to be included in the source files and for parallel programming and so do others so support is on-going.
Templating has only recently become a significant need, as I mostly deal with 64-bit floats and default intrinsic types or at least user-defined types defined with a small variation of intrinsic types myself, but I see the need; so one near-term planned upgrade is to improve the templating features.
So prep(1) is something I will continue to need, but from the (lack of) response I saw in any adoption of it here as a starting point for a ubiquitious tool my only current plans are to improve the template capabilities, to possibly add an option for generating a single output file for project-specific reasons, to make an fpp-compatible mode and to make it support more pre-defined macro values. That is particularly vexing as it is an important feature but making calls to the compiler to dump the pre-defined macros (which initially seemed promising) and then importing them had more issues than I hoped.
So I do not see prep(1) replacing all the various pre-processors (including fypp(1) or any other new or existing processor) but I see it as a tool I need that is a platform-independent Fortran-based tool that lets me write better code faster that I can easily extend when I need too. It sounded like it would fit a niche for others too, and if so they are welcome to use it in any fashion but I did not see any major indication here with this effort that it or any other preprocessor will be a single standard preprocessor for Fortran any time soon without J3 and the compiler vendors getting behind such an effort, although I took a stab at making prep(1) a seed for starting a community-based effort in that direction (in particular with fpm(1) usage). Didn’t see much of a spark or feedback though, so I wanted to get back to a few other things for now, aside from a newer expression parser I have as the current one in prep(1) has been quite adequate for what I need, but leverages some old F77 code that could stand a refresh.
I still think there would be great value in a preprocessor being distributed with fpm(1). When I distribute something like a library myself I distribute the output files from prep(1) as .f90 files and rarely as .F90 files (assuming fpp/cpp is available). Over 90% of the files in my GPF github repository are actually maintained as .ff (my preferred prep(1) file suffix) but all distributed as .f90 files. It would be useful to be able to distribute files that needed more extensive preprocessing as-is but I don’t see that being a good path forward yet except for fpp-compatible directives (for now).
Actual answers …
So I think guidelines about preprocessing would still be useful and that perhaps we can start a Fortran Wiki or fortran-lang collaborative document about it; but I cannot distribute my old paper.
prep(1) apparently did not light any fires but I use it myself and the source is a simple Fortran code (and Fortran is notoriously good at upward compatibility) so it is a good tool to depend on if it is a good fit for you; but I think fypp(1) also looks like it will be around a while too.
I am more a fan of the idea of fpm(1) supporting preprocessing in general than a particular one, but think even given that that having one bundled with fpm(1) would be useful, and personally would prefer it to be Fortran-based like Nagle’s COCO(1) or prep(1).
Along those lines I think I want a starting base of a Fortran-based fpp-ish preprocessor available first, and then some in-source documentation support and templating added to that; but others have other needs. The biggest fight there is that fpp(1) itself is not standardized and varies widely in how or if it supports macros with parameters.