Hi Nick, Thanks for that.
I thought about it a bit and guess that this would *always* define the COPYFILE_DISABLE=1. That is, not just in “make dist” but also in other targets, correct? I think that isn’t what I want as I don’t want to go too much against the filesystem defaults, to avoid potential troubles :) Or am I missing something? Shouldn’t this be solved inside autotools itself? I guess it is something valid for every Mac user who creates a distribution on Mac…. and I guess it is exactly these kind of OS differences autotools is trying to resolve? Thanks, Bas > On 14 May 2015, at 9:24 pm, Nick Bowler <nbow...@elliptictech.com> wrote: > > Hello, > > On 2015-05-10 12:57 +0000, Bas Vodde wrote: >> I'm trying to change my projects configure.ac so that it sets the >> COPYFILE_DISABLE=1 environment variable to influence the make dist >> target. >> >> Background: The COPYFILE_DISABLE=1 avoids having a second top-level >> directory in your package when packaging on MacOSX. >> >> So far, my attempt was to set the variable in the configure.ac file >> and use AC_SUBST on it, but that didn't seem to work. > > Right. AC_SUBST([COPYFILE_DISABLE]) ordinarily does two things: > > - config.status will substitute @COPYFILE_DISABLE@ in output files > - it causes Automake to put a line like this: > > COPYFILE_DISABLE = @COPYFILE_DISABLE@ > > into the Makefile.in files it generates. > > Unfortunately this alone is not sufficient, because make variables are > not generally exported into the environment (which is what you actually > want to happen). > > But I think there is a solution: we can (ab)use the fact that 'make dist' > internally performs a recursive make invocation. This gives us the chance > to add things to the make command line, using AM_MAKEFLAGS. So putting > > AM_MAKEFLAGS = COPYFILE_DISABLE='$(COPYFILE_DISABLE)' > > into Makefile.am should work I think (not tested), because variables > defined on the make command line *are* exported into the environment. > You will still need the AC_SUBST to define COPYFILE_DISABLE in the > first place. > > Regards, > -- > Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)
