[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Setting environment variable for make dist

From: Bas Vodde
Subject: Re: Setting environment variable for make dist
Date: Wed, 20 May 2015 10:17:40 +0800

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!


> 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
>>> into 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]
> Regards,
> -- 
> Nick Bowler, Elliptic Technologies (

reply via email to

[Prev in Thread] Current Thread [Next in Thread]