I was told to bring this issue to r-devel or r-package-devel. It appears to me that package-devel is the more appropriate of the two for this issue.
referencing this RcppEigen issue: https://github.com/RcppCore/RcppEigen/issues/74 I presume the line in the policy document: "Packages should not attempt to disable compiler diagnostics, nor to remove other diagnostic information such as symbols in shared objects." is what is driving this interpretation. If there are other relevant policy lines I’m open to being disabused of my errant understanding, but this one jumped out at me as a likely candidate for what is driving this issue. is their understanding of CRAN policy accurate? Would you really treat wrapping directives so that they’re only used in appropriate circumstances as if it were the equivalent to tampering with compiler diagnostics (such as using a -Wno flag)? to me this stance doesn't make very much sense, but I presume there had to have been a lot of thought and reasoning put into this. I’d like to be helped to understand this policy choice, as it applies to this specific kind of issue (making sure that only supported preprocessor statements are used as is generally viewed as appropriate when writing C / CXX code). There is a difference between preventing the occurrence of an inappropriate line of code (i.e. wrapping a pragma directive that some versions of a compiler cannot understand or use and will issue complaints about in #if conditionals that ensure the pragma will be understood by the compiler) from being provided to the compiler / preprocessor / linker etc., and merely silencing such a warning that the compiler would otherwise be issuing (i.e. using a -Wno-warnings style flag to hide the complain, but still leaving it fully visible in the source file, and thus not actually addressing the error in syntax/usage for the particular compiler or platform). I do not think that that approach is equivalent to tampering with compiler diagnostics, or suppressing a warning in the same way that using -Wno flags would be, but i'm being told that CRAN will treat that as equivalent to warning-silencing. Is this true? What is the justification for that stance? It would seem to me that this policy choice results in bad programming practices, such as leaving in preprocessor directives for platforms that cannot understand them. In any other context, platform specific preprocessor driven inclusion or exclusion of code to ensure that only appropriate code is used for a given compiler or platform would likely not be objected to, so why it be a problem in a case such as this? Not providing a directive to the preprocessor when it is not appropriate and not supported for either the platform or the compiler itself is not tampering or disabling a diagnostic, it is making an appropriate choice so as NOT to create an error in the code. It so happens that the compiler in question can warn about the issue and proceed without preventing compilation and functional use of the code, but the warning in this case is still telling the developer that there is an inappropriate piece of code present in the source, and that OUGHT to be something one can remedy by detecting the compiler (and its version) and ensuring that only compilers that support the directives are actually provided with those directives. That doesn’t appear to be tampering, or a malicious/anti-social development decision, that would seem to be an entirely appropriate and proper use of the preprocessor. Trying to silence the warning with a -Wno flag WOULD be doing that, but wrapping the pragma in a conditional so that it only exists when it will have a functional utility is not much different from having OS specific implementation files optionally included or excluded from the source dependent on the platform. It certainly WOULD have the net effect of the warning no longer being issued, but that would be because the errant lines are never provided to the preprocessor in the first place, which itself is actually an error, and as such should NOT be the state of affairs that CRAN policy demands. it seems entirely backward from what one ought to expect the developer to do. If I am misguided in thinking that there is a difference between telling the compiler to ignore/silence a warning, as opposed to preventing an inappropriate line of code from being provided/used by the compiler in the first place, please help me to understand, because I’m really having a hard time seeing those as the same thing. M. Gooch [[alternative HTML version deleted]] ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
