Re: Setting environment variable for make dist

[Bas Vodde]

Hi Nick,

Ok, thanks.

I don’t know the side-effects of the COPYFILE_DISABLE flag, so I prefer not to 
use it other than make dist.

Good to see the open bug report and hope it’ll be fixed sometime in the future.

In the mean time, I decided to write some code in the dist-hook to check if the 
environment varialble is set on MacOsX and fail the build if it isn’t (with the 
error message it should be set).

That still doesn’t solve it, but it ensures that I can’t make the mistake of 
not setting it in the future anymore.

Thanks for your help on this!

Bas


> On 19 May 2015, at 9:17 pm, Nick Bowler <address@hidden> wrote:
> 
> Hello,
> 
> On 2015-05-18 16:10 +0800, Bas Vodde wrote:
>> On 14 May 2015, at 9:24 pm, Nick Bowler <address@hidden> wrote:
>>> 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.
>> 
>> 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?
> 
> The flags will be passed on recursive make invocations, so it will be
> defined whenever that happens.
> 
> This includes targets like 'make all', 'make clean' and 'make dist', but
> does not normally include targets like 'make src/foo.o'
> 
>> 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 :)
> 
> Does the COPYFILE_DISABLE=1 flag affect more than just the 'tar'
> behaviour?  Then yeah, there may be potential troubles.  It would be
> good to characterize the effects of this flag.
> 
>> 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?
> 
> This does sound like a portability problem that Automake could solve.
> There is a related bug report[1].
> 
> With recent-ish versions of Automake you could try fitzing with the TAR
> environment variable instead, together with a suitable configure test.
> This might be trickier to get right, however.
> 
> [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=9822
> 
> Regards,
> -- 
> Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)