[R-pkg-devel] Problematicness of Makefile Extensions for CRAN Packages

[Dirk Eddelbuettel]

On 28 September 2025 at 11:00, Nils Lüschow wrote:
| when performing "R CMD check" on my package that contains the sourcecode 
| of a third party C++ library, I get a warning telling me to avoid the 
| usage of makefile extensions. Before going ahead and trying to temper 
| with the library's build-process, I just wanted to ask how severe of a 
| problem makefile extensions are. Is there a "gradient" i.e. makefile 
| extensions can be tolerated to a certain degree and some are worse than 
| others, or are they such a problem with regards to portability that you 
| shouldn't use them at all?

See Section 1.6 "Writing Portable Packages" of _Writing R Extensions_ under
the bullet point for `make`:

   • If your package has a ‘Makevars’ or ‘Makefile’ file, make sure that
     you use only portable make features.  Such files should be
     LF-terminated(2) (including the final line of the file) and not
     make use of GNU extensions.  (The POSIX specification is available
     at
     <https://pubs.opengroup.org/onlinepubs/9699919799/utilities/make.html>;
     anything not documented there should be regarded as an extension to
     be avoided.  Further advice can be found at
     <https://www.gnu.org/software/autoconf/manual/autoconf.html#Portable-Make>.
     )  Commonly misused GNU extensions are conditional inclusions
     (‘ifeq’ and the like), ‘${shell ...}’, ‘${wildcard ...}’ and
     similar, and the use of ‘+=’(3) and ‘:=’.  Also, the use of ‘$<’
     other than in implicit rules is a GNU extension, as is the ‘$^’
     macro.  As is the use of ‘.PHONY’ (some other makes ignore it).
     Unfortunately makefiles which use GNU extensions often run on other
     platforms but do not have the intended results.

     Note that the ‘-C’ flag for ‘make’ is not included in the POSIX
     specification and is not implemented by some of the ‘make’s which
     have been used with R. However, it is more commonly implemented
     (e.g. by FreeBSD ‘make’) than the GNU-specific ‘--directory=’.

     You should not rely on built-in/default ‘make’ rules, even when
     specified by POSIX, as some ‘make’s do not have the POSIX ones and
     others have altered them.

     The use of ‘${shell ...}’ can be avoided by using backticks, e.g.

          PKG_CPPFLAGS = `gsl-config --cflags`

     which works in all versions of ‘make’ known(4) to be used with R.

     If you really must require GNU make, declare it in the
     ‘DESCRIPTION’ file by

          SystemRequirements: GNU make

     and ensure that you use the value of environment variable ‘MAKE’
     (and not just ‘make’) in your scripts.  (On some platforms GNU make
     is available under a name such as ‘gmake’, and there
     ‘SystemRequirements’ is used to set ‘MAKE’.)  Your ‘configure’
     script (or similar) does need to check that the executable pointed
     to by ‘MAKE’ is indeed GNU make.

     If you only need GNU make for parts of the package which are rarely
     needed (for example to create bibliography files under
     ‘vignettes’), use a file called ‘GNUmakefile’ rather than
     ‘Makefile’ as GNU make (only) will use the former.

     macOS has used GNU make for many years (it previously used BSD
     make), but the version has been frozen at 3.81 (from 2006).

     Since the only viable make for Windows is GNU make, it is
     permissible to use GNU extensions in files ‘Makevars.win’,
     ‘Makevars.ucrt’, ‘Makefile.win’ or ‘Makefile.ucrt’.

You either comply, or you declare 'SystemRequirements: GNU make' as many
packages do. There is no gradient here.

Hope this helps, Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | edd using debian.org