Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Response files #2

Open
ivan-pi opened this issue Aug 31, 2022 · 4 comments
Open

Response files #2

ivan-pi opened this issue Aug 31, 2022 · 4 comments

Comments

@ivan-pi
Copy link

ivan-pi commented Aug 31, 2022

Does prep recognize response files? I could not find the keyword "response" in the documentation at least. If you want to use prep with the Intel Fortran compiler option -fpp-name it appears a response file is necessary: aradi/fypp#24

@urbanjost
Copy link
Owner

There is no standard for response files; the latest version of prep uses M_CLI2 to parse the command line (it used M_kracken until recently). The M_CLI2 parser supports response files but it's own format.

@urbanjost
Copy link
Owner

It would be possible to read the parameters from the @ file without much effort, but that is not even documented and would work as-is with no alternate preprocessor I know of. I made a wrapper that gets the response file to look at and it does not have a space between -D and -I and the values

-D__INTEL_COMPILER_UPDATE=3
-D__unix__
-D__unix
-D__linux__
-D__linux
-D__gnu_linux__
-Dunix
-Dlinux
-D__ELF__
-D__x86_64
-D__x86_64__
-D__amd64
-D__amd64__
-D__INTEL_COMPILER_BUILD_DATE=20210609
-D__INTEL_OFFLOAD
-D__MMX__
-D__SSE__
-D__SSE_MATH__
-D__SSE2__
-D__SSE2_MATH__
-D__pentium4
-D__pentium4__
-D__tune_pentium4__
-I.
-I/opt/intel/oneapi/tbb/2021.3.0/env/../include
-I/opt/intel/oneapi/mpi/2021.3.0//include
-I/opt/intel/oneapi/dev-utilities/2021.3.0/include
-I/opt/intel/oneapi/compiler/2021.3.0/linux/include
-I/opt/intel/oneapi/compiler/2021.3.0/linux/bin/intel64/../../compiler/include/intel64
-I/opt/intel/oneapi/compiler/2021.3.0/linux/bin/intel64/../../compiler/include/icc
-I/opt/intel/oneapi/compiler/2021.3.0/linux/bin/intel64/../../compiler/include
-I/usr/local/include
-I/usr/lib/gcc/x86_64-linux-gnu/9/include
-I/usr/include/
-I/usr/include
-I/usr/include/x86_64-linux-gnu
/tmp/xx.F90

so that would be another issue. As appealing as the -fpm-name: parameter seems at first it would be
easier to just preprocess first. With gfortran you can use the -x option to compile stdin, so you can pipe from the preprocessor to the compiler.

The big advantage of making it work would be that you could use the -D values defined by the ifort command in the source conditionals so you could have prep(1) directives using the INTEL_COMPILER variable automatically (it would then be easy to have conditionals based on the compiler being used, for example.

I have a feeling no one is using this because of the response file. Will be interested in the Intel response on response files.

@ivan-pi
Copy link
Author

ivan-pi commented Sep 1, 2022

I have a feeling no one is using this because of the response file. Will be interested in the Intel response on response files.

Let's wait and see.

I think the idea of Intel's preprocessor flag is not bad. For "isolated" projects where you are linking exclusively with precompiled shared and static libraries, you can tune the compiler command to your liking via the config file (ifort.cfg). The benefit is you don't need to maintain a "manual" preprocessing step in your build system. So this is really just when you are "confined" to one particular platform (a cluster where you expect to use nothing but Intel Fortran + prep/fypp/xyz for the foreseeable future).

For larger codes where you bring in third-party sources which might need other preprocessors (the default fpp or fypp) the config file approach doesn't work. It would seem a better idea to provide compiler wrapper scripts such as ifx-prep and ifx-fypp so you can use them in parallel depending on the source-file extensions.

@urbanjost
Copy link
Owner

I use wrappers myself with fpm; as well as the response file supported by M_CLI2. An advantage that a preprocessor called by the compiler has is those -D parameters. I have used the ifort configuration file extensively, as we preferred for years to have static loading the default, etc. You can point to multiple files and supply options via environment variables too, which I sometimes use with fpm instead of specifying a lot of -flag options. I think they got a lot of that right, but the preprocessor option does not seem to be worked out to well for anything except testing different versions of their own fpp program.

Really nice idea till reality sets in!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants