Consistency of the command-line interface with other preprocessors

[ivan-pi]

Would it be possible to make the CLI of prep consistent with other Fortran preprocessors?

Namely, if one is to use a third-party preprocessor with the Intel Fortran compiler, the alternative preprocessor should support an invocation of the form:

alt_fpp [ [–D<define>]..] [[-I<include directory>]..] inputfile 

with output redirected to STDOUT. Currently, prep requires an -i for the input file, meaning a wrapper-script would be needed.

Also the fypp preprocessor uses a "positional" argument for the input file:

$ fypp -h
Usage: fypp [options] [INFILE] [OUTFILE]

Preprocesses source code with Fypp directives. The input is read from INFILE
(default: '-', stdin) and written to OUTFILE (default: '-', stdout).

I have not investigated the conventions of other fpp- and cpp-like Fortran preprocessors.

If not possible for whatever reasons, I'm happy to contribute a note on how to "embed" the prep preprocessor with other tools.

[urbanjost]

ly like being able to specify multiple input files with multiple -i switches or a list of files for -i, and not having to keep repeating -D when I have a lot of variables, like "prep LINUX GFORTRAN ...." instead of "fpp -D LINUX -D GFORTRAN -D ...". , but it would be very easy to change. Note prep(1), at least currently, requires a space after the -D (I have been thinking about allowing that as it seems commonly used, but newer references discourage not having a space). It would be a non-compatible change as well. It would be easy to do with an environment variable or the name of the executable as a switch between the two modes, but the environment variable would be easy to forget to set. It would also be easy to have it be a build switch to let you build one way or the other.

I was making a fpp(1) compatible version not too long ago, defaulting to "#" instead of "$" for a prefix and with command line options just like you described, and treating all #DEFINE directives as strings like cpp and most fpp do instead of an expression (which I dislike, and not all fpp allow; but people seem to live with) and decided I had to reintroduce the things I do not like to be completely fpp or cpp compatible or confuse people with something so fpp/cpp-like that really was not the same so I stopped;
so I even have the code change required in file laying around (it acted just like you propose).

Seems like a valuable change though, as ifort is one of the principal compilers and it is unlikely I could get them to change ifort to handle prep(1) as-is. I was thinking I could add a prep to switch like "-fpp" but that would be inconvenient to use with ifort/ifx also.

What do you think about it behaving like that if the binary is renamed to something like prep_alt or prep+ or something like that? The program could look at arg0 and if it is not "prep" the behavior changes? Not ideal for a couple of reasons (fpm does not allow specifying an install name, people would have to make a copy themselves in their path if prep(1) was not installed somewhere writable by them, it kludges the code. Any other options?

I could just bite the bullet and change it, but being a non-upward-compatible change I am trying to think of an alternative, and wondering who else it would effect (and of course, Otherwise I would just change it, even though I personally like how it is now.

[ivan-pi]

I like being able to specify multiple input files with multiple -i switches or a list of files for -i, and not having to keep repeating -D when I have a lot of variables,

Fair point.

Note prep(1), at least currently, requires a space after the -D (I have been thinking about allowing that as it seems commonly used, but newer references discourage not having a space). It would be a non-compatible change as well.

In the tools I'm familiar with (CMake, compilers) I'm used to the syntax with no space. Which newer references discourage this?

It would be easy to do with an environment variable or the name of the executable as a switch between the two modes, but the environment variable would be easy to forget to set. It would also be easy to have it be a build switch to let you build one way or the other.

Environment variables are easy to forget. Build-time switch for two executable with a different CLI but the same name is also a bad idea. The incompatibilities between different versions of fpp or Make are two such "criminal" examples.

I was making a fpp(1) compatible version not too long ago, defaulting to "#" instead of "$" for a prefix ... to be completely fpp or cpp compatible or confuse people with something so fpp/cpp-like that really was not the same so I stopped;

I think using $is the right decision to keep prep distinguishable. Hopefully, Fortran will not introduce the $ symbol anytime soon.

Seems like a valuable change though, as ifort is one of the principal compilers and it is unlikely I could get them to change ifort to handle prep(1) as-is.

Based on the lukewarm response I received at the Intel Forum currently, it looks like Intel has more important jobs on their plate. Their documentation is broken, so it must mean that no "big" customer is relying on the alternative preprocessor compile switch.

What do you think about it behaving like that if the binary is renamed to something like prep_alt or prep+ or something like that?

Adapting to everyones needs is a pain. Providing a second "binary" (potentially just a bash script) with an alternative name seems like the best solution to me. It doesn't even need to be part of the prep repository, but it could just be a paragraph in the man page: "If you'd like to use prep as alternative preprocessor with ifort..."

I could just bite the bullet and change it, but being a non-upward-compatible change I am trying to think of an alternative, and wondering who else it would effect (and of course, Otherwise I would just change it, even though I personally like how it is now.

There is no point in changing the behavior on a single user request when your whole personal (and professional) development environment relies on the current behaviour. Personally, I would defer the decision until a day when Intel clarifies their stance, and potentially other compilers (LFortran?) show their willingness to follow suit.

Given how unknown the Intel option is anyways, I guess there is little to no value to pursue this currently. Moreover, for (future) users interacting with prep via fpm, it shouldn't be a problem.

[urbanjost]

prep now, under these conditions, uses the cpp syntax:
If there are only two or less unnamed options and the first is a file that exists and the -i option is not present the first option is taken to be an input file and not a macro definition; and the second is then taken as an optional output file. This should conform to the common cpp/fpp conventions. I also changed M_CLI2 to have a strict mode where a single dash implies short single-character options, and two dashes a long option; which then allows for no space after the -D. As well, if the response file first line is not in the defined M_CLI2 response file format it is assumed to merely be a file of command options.

This let me use prep as an alternate preprocessor for basic direct usage with ifort as-is; but some options like -E still caused problems, and even though it worked with basic ifort commands I got errors I have not tracked down when I tried to use it with fpm(1). It still has support / lack-of-standardization options; and their might be a collision between fpm and M_CLI2 preventing the problem; and since fpm(1) preprocessing apparently only allows cpp/fpp and fypp I had to rename prep to either cpp or fpp and other kludges; but simple prep usage by those used to cpp/fpp should be possible now, so I will leave the changes in. So you can use "prep -D A=10 -DB infile", without the -i for example. I