Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Newer tar causes make dist to fail

(1/1)

oBFusCATed:
I'm getting this error:

--- Code: ---tardir=codeblocks-17.12svn11451 && /bin/sh /home/obfuscated/projects/codeblocks/temp_svn/missing --run tar chf - "$tardir" --exclude=".svn" | bzip2 -9 -c >codeblocks-17.12svn11451.tar.bz2
tar: The following options were used after any non-optional arguments in archive create or update mode.  These options are positional and affect only arguments that follow them.  Please, rearrange them properly.
tar: --exclude ‘.svn’ has no effect
tar: Exiting with failure status due to previous errors
tar: The following options were used after any non-optional arguments in archive create or update mode.  These options are positional and affect only arguments that follow them.  Please, rearrange them properly.
tar: --exclude ‘.svn’ has no effect
tar: Exiting with failure status due to previous errors
WARNING: I can't seem to be able to run `tar' with the given arguments.
         You may want to install GNU tar or Free paxutils, or check the
         command line arguments.
{ test ! -d codeblocks-17.12svn11451 || { find codeblocks-17.12svn11451 -type d ! -perm -200 -exec chmod u+w {} ';' && rm -fr codeblocks-17.12svn11451; }; }

--- End code ---

It seems that it is cause by a newer version of tar (1.30 or 1.29) which is more strict with its parameters.

If I remove this line

--- Code: ---am__tar = @am__tar@ $(ADDITIONAL_MAKE_DIST_OPTIONS)
--- End code ---

from Makefile.am it works and it seems there aren't bad files in the created archive.
Do you think this is a safe change?

oBFusCATed:
Ping?

sodev:
Pong!

This depends on if codeblocks-17.12svn11451 is the root directory of your working copy or not. Non-ancient svn clients put the .svn directory only in the root directory, from the command line it looks like you are tar-ing a subdirectory, so you should be fine without the exclude.

But if you remove that line, you should remove the second line below this as well, because it suffers from the same problem. But then you break that KEEP_DLLS feature, which technically is already broken :).

Actually it is a good idea to remove that whole am__tar replacement stuff, because according to my tar.m4 file this might not even call tar but something else, although i don't know under what obscure conditions that might happen. My understanding of Automake Magic is ... quite limited, zero is a valid limit :D.

oBFusCATed:
OK, I've so used to now do build in my checkout dir that I forgot for this case. I'll test and I'll see what happens.

Navigation

[0] Message Index