[R-pkg-devel] Misusing CFLAGS?

[Pepijn de Vries]

Hi Simon,

Thank you for the clarifications. I changed my setup from anticonf to autoconf. I think this will address a few of the issues, I think it now logs compilation errors more clearly. I'm also no longer relying on brew, nor suggesting it.

I will also update the searching path on MacOS, when pkg-config fails, and not hardcode the architecture as you suggested.

Cheers,

Pepijn

________________________________________
Van: Simon Urbanek <simon.urbanek using R-project.org>
Verzonden: dinsdag 9 september 2025 00:23
Aan: Pepijn de Vries <pepijn.devries using outlook.com>
CC: List r-package-devel <r-package-devel using R-project.org>
Onderwerp: Re: [R-pkg-devel] Misusing CFLAGS?
 
Pepijn,

the comment points out three somewhat separate issues:

a) recommending brew is generally not a good idea especially for something as lightweight (brew tends to cause conflicts with the system) - not that it prevents people from doing it ;)

b) the test doesn’t log the compiler call, so it doesn't show the actual compiler invocation with flags - which is crucial to be able to say where the problem lies on error

c) the test uses incomplete flags - it fails to include CXXFLAGS in the test (I assume that is the CFLAGS comment, but if not sure you can ask for clarification).

Looking at the file I see another problem as well - this fallback is most certainly wrong:

  for pre in /usr /usr/X11 /usr/X11R6 /usr/local /opt /opt/R/arm64 opt/R/x86_64 /sw; do

I don’t think you should use headers from another platform and/or hard-code them (I’m looking the the two odd "/opt/R/arm64" and "opt/R/x86_64" entires). Also unclear why the latter is missing leading slash? At the moment you can get away with something like /opt/R/$(uname -m), but technically the architecture may be defined by ${R_ARCH} instead, although we avoided using it recently, because people often ignore it and then it causes issues. (I principle this is moot, since if you have any of those, then they should be on the PATH so likely it is a user error to start with).

Cheers,
Simon


> On 9/09/2025, at 03:23, Pepijn de Vries <pepijn.devries using outlook.com> wrote:
>
> Hi all,
>
> A CRAN check report after a manual inspection confuses me a bit. Hopefully someone can help me interpret. I received the following feedback based on M1mac checks:
>
> _"He really should not be recommending Brew for macOS ... Since it does not log the configure output, issues such as misusing CFLAGS are suppressed (a usual 'anticonf' failing)."_
>
> I use a modified 'anticonf' (by Jeroen Ooms) configure script. When a specific header file (blosc.h) is not found, an error is produced and the submitted version echos the suggestion to install the library with Brew. I know this is not the preferred method for linking to binaries on MacOS. I have already adjusted it to suggest the preferred method for setting this up (using https://mac.R-project.org/bin/install.R). So this should take care of the first part of the feedback.
>
> I'm confused about the second part of the feedback. Is it related to the first part? Or is it a completely separate issue? If it is a completely separate issue, how am I misusing CFLAGS?
>
> Latest version of my configure script is available here: <https://github.com/pepijn-devries/blosc/blob/d43b95fa3ba5c01efa11ffcf14ddfa3fca63988e/configure>
>
> Any assistance is much appreciated!
>
> Kind regards,
>
> Pepijn
> ______________________________________________
> R-package-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>