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

Missing space before -D when specifying preprocessing from the fpm.toml file #803

Closed
urbanjost opened this issue Nov 25, 2022 · 1 comment · Fixed by #804
Closed

Missing space before -D when specifying preprocessing from the fpm.toml file #803

urbanjost opened this issue Nov 25, 2022 · 1 comment · Fixed by #804
Labels
bug Something isn't working

Comments

@urbanjost
Copy link
Contributor

urbanjost commented Nov 25, 2022

Description

Depending on the options used, the first -Dname=value is not always separated by a space from the preceding option.

Update: PR #804 fixes the space problem.

When specifying macro definitions a space is missing before the first -D
option on the compilation in many cases when non-default options are used.
I will submit a PR shortly to address that, as a very simple fix is to
change the macro prefix from "/D" or "-D" to " /D" or " -D".

It would be nice if more than the "{version}" key from the manifest would
work, as I thought was the case from the description. If any manifest key
could be used, including keys in the "extra" section of the fpm.toml that would be useful.

Under that assumption, I was making a M_manifest package that, if used
as a dependency would allow for all the keys to be accessible as strings
from a module, and to auto-generate a "manifest_version()" procedure that
would list the module values that were used at the time of the build,
such as author, copyright, .... .

I found only "version" was defined. I think it would be useful to make
it more generic, and allow the OS and compiler to be passed as well,
which are often what conditionals are based on, and inconsistently set
as predefined variables if set at all.

But that brought up another issue where it only appears that the first
compile has -DVERSION=0.1.0 set, with it appearing as -DVERSION= subsequently,
and some multiple compiles of files, and I am surprised three directories
are made in the build directory. So far, that only occurs when macros and
preprocessing occur but in several tests resulted in executables built without
the preprocessing I expected. Still tracking that down, but the simpler
problem described above can be easily addressed.

fpm new A
cd A
cat >>fpm.toml <<\EOF
[preprocess]
[preprocess.cpp]
macros=["VERSION={version}"]
EOF
fpm build --compiler ifort --verbose
 + mkdir -p build/dependencies
 <INFO> BUILD_NAME: build/ifort
 <INFO> COMPILER:  ifort
 <INFO> C COMPILER:  icc
 <INFO> CXX COMPILER: icpc
 <INFO> COMPILER OPTIONS:  -fpp -warn all -check all -error-limit 1 -O0 -g -assume byterecl -traceback
 <INFO> C COMPILER OPTIONS:  
 <INFO> CXX COMPILER OPTIONS: 
 <INFO> LINKER OPTIONS:  
 <INFO> INCLUDE DIRECTORIES:  []
 + mkdir -p build/ifort_5F88F33E64426170
 + mkdir -p build/ifort_CA1AA31787AA8435
 + mkdir -p build/ifort_CA615F8C0CE7D1DA
[  0%]                          A.f90
 + mkdir -p build/ifort_CA1AA31787AA8435/A/
 + ifort -c ././src/A.f90 -fpp -warn all -check all -error-limit 1 -O0 -g -assume byterecl -traceback-DVERSION=0.1.0 -module build/ifort_CA1AA31787AA8435 -Ibuild/ifort_CA1AA31787AA8435 -Ibuild/ifort_CA615F8C0CE7D1DA -o build/ifort_CA1AA31787AA8435/A/src_A.f90.o
[ 25%]                          A.f90  done.
[ 25%]                         libA.a
 + mkdir -p build/ifort_5F88F33E64426170/A/
 + ar -rs build/ifort_5F88F33E64426170/A/libA.a build/ifort_CA1AA31787AA8435/A/src_A.f90.o
ar: creating build/ifort_5F88F33E64426170/A/libA.a
[ 50%]                         libA.a  done.
[ 50%]                       main.f90
 + mkdir -p build/ifort_CA615F8C0CE7D1DA/A/
 + ifort -c app/main.f90 -fpp -warn all -check all -error-limit 1 -O0 -g -assume byterecl -traceback-DVERSION= -module build/ifort_CA615F8C0CE7D1DA -Ibuild/ifort_CA1AA31787AA8435 -Ibuild/ifort_CA615F8C0CE7D1DA -o build/ifort_CA615F8C0CE7D1DA/A/app_main.f90.o
[ 75%]                       main.f90  done.
[ 75%]                              A
 + mkdir -p build/ifort_5F88F33E64426170/app/
 + ifort -fpp -warn all -check all -error-limit 1 -O0 -g -assume byterecl -traceback  build/ifort_CA615F8C0CE7D1DA/A/app_main.f90.o build/ifort_5F88F33E64426170/A/libA.a -o build/ifort_5F88F33E64426170/app/A
[100%]                              A  done.
[100%] Project compiled successfully.

Expected Behaviour

Expected -traceback -DVERSION=0.1.0 but the space after -traceback is absent

Version of fpm

0.7.0

Platform and Architecture

All that I know of

Additional Information

No response

@urbanjost urbanjost added the bug Something isn't working label Nov 25, 2022
@urbanjost
Copy link
Contributor Author

urbanjost commented Nov 25, 2022

Could someone with access to MSWindows and ifort let me know if the prefix on that processor needs a trailing space?
Not sure if " /DNAME=VALUE" is OK or needs "/D NAME=VALUE".

Never mind. Looks like no space to me:

https://www.intel.com/content/www/us/en/develop/documentation/fortran-compiler-oneapi-dev-guide-and-reference/top/compiler-reference/compiler-options/preprocessor-options/d.html

@awvwgk awvwgk linked a pull request Nov 26, 2022 that will close this issue
@awvwgk awvwgk closed this as completed in 58c4667 Nov 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant