Re: [R-pkg-devel] Build process generated non-portable files

[Ivan Krylov via R-package-devel]

В Mon, 12 Aug 2024 18:24:30 +
David via R-package-devel  пишет:

> in the intel environment (provided by rhub), the intel fortran
> compiler generates intermediary files from *.f -> *__genmod.f90. The
> R check then complains that the genmod files are not portable. I
> include removal of the files in my cleanup file so the files do not
> exist in the original package source or in the final source tarball
> but it seems the portable files check is done after compilation but
> before cleanup.
> 
> - Is there a way to get around this complaint?

Include the first 'all' target in your Makevars, make it depend on the
package shared library, and make it remove genmod files in the recipe:

all: $(SHLIB)
-rm -f arpack/*genmod.f90

A similar trick is mentioned in
.

> - Should this complaint be here in the first place?

Perhaps not. If you manage to find an option for the ifx compiler that
disables creation of these files (a brief Web search says they are for
only the user to read, but most results are from early 2010's), post it
here. This may be a good argument to make this option recommended for R.

> Shouldn't the portable files check only be performed on the shipped
> source code?

False negatives are possible too, in case the installation stage
(configure and/or make) performs a lot of preprocessing, or unpacks
extra sources. You could be right; I don't have statistics to back
either option as less wasteful of effort.

-- 
Best regards,
Ivan

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [R-pkg-devel] Build process generated non-portable files

[Jisca Huisman]

I'm not familar with fortran but the warning message is: "Found the following files with 
non-portbale usage of KIND:." In "Writing R Extensions/Writing portable packages/Portable 
Fortran code" it mentions the use of REAL(KIND=8)​ types are not portable since compilers can 
map values to different types (and these declarations are in the f90 files), but the compiler 
called the preprocessing of the files so it should be correct for this specific compiler.


This might actually be the main problem. As it says, REAL(KIND=8) does 
not have a consistent defintion, but the most common definition is 
double the precision of a default REAL (commonly KIND=8). So, replacing 
all 'REAL(KIND=8)' by 'DOUBLE PRECISION' in declarations should (might) 
solve the error message. Alternatively, you could use 
selected_real_kind(), see 
https://fortranwiki.org/fortran/show/Real+precision .


Best,

Jisca



On Tue, 13/08/2024 10:08, Ivan Krylov via R-package-devel wrote:

В Mon, 12 Aug 2024 18:24:30 +
David via R-package-devel  пишет:


in the intel environment (provided by rhub), the intel fortran
compiler generates intermediary files from *.f -> *__genmod.f90. The
R check then complains that the genmod files are not portable. I
include removal of the files in my cleanup file so the files do not
exist in the original package source or in the final source tarball
but it seems the portable files check is done after compilation but
before cleanup.

- Is there a way to get around this complaint?

Include the first 'all' target in your Makevars, make it depend on the
package shared library, and make it remove genmod files in the recipe:

all: $(SHLIB)
-rm -f arpack/*genmod.f90

A similar trick is mentioned in
.


- Should this complaint be here in the first place?

Perhaps not. If you manage to find an option for the ifx compiler that
disables creation of these files (a brief Web search says they are for
only the user to read, but most results are from early 2010's), post it
here. This may be a good argument to make this option recommended for R.


Shouldn't the portable files check only be performed on the shipped
source code?

False negatives are possible too, in case the installation stage
(configure and/or make) performs a lot of preprocessing, or unpacks
extra sources. You could be right; I don't have statistics to back
either option as less wasteful of effort.



__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel