You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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".
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.
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
The text was updated successfully, but these errors were encountered: