This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH: Avoid command line length limit building tools.zip (PR libgcj/38251)


Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> writes:

> I've finally looked into PR libgcj/38251 again where building tools.zip
> in classpath/tools fails on systems with low limits on command line
> lenght.  I think the solution is obvious on second thought: instead of
> passing all file names except those below to .svn to jar/zip explicitly,
> just prune the copies of the classes and asm directories of .svn subdirs
> and then archive the whole remaining hierarchy.  The following patch
> (only lightly tested so far) does just that.
>
> A few caveats, though:
>
> * The test for the .svn dir must check in asm (or classes), since in a
>   VPATH build, there will be no .svn directory otherwise.
>
> * find | xargs is a problem for filenames containing whitespace, but
>   find -print0/xargs -0 or Sun's find -exec \{\} + aren't portable.
>
> Ok for mainline anyway?

Proper testing revealed a couple of problem, fixed by this patch which
survived a full bootstrap on alpha-dec-osf4.0f and alpha-dec-osf5.1b.
The ChangeLog is unchanged, but the patch itself needed some
adjustments:

* The [ -d asm/.svn ] && find ... construct doesn't work because if the
  .svn directory doesn't exist (like in a hg checkout), make aborts
  since the command exits with exit status 1.  Thus I wrap the find in
  if [ -d asm/.svn ] instead.

* Even so, find complaints

  $ find asm -type d -name .svn -exec rm -rf \{\} \;
  find: asm/.svn: No such file or directory

  Using find -depth instead cures this.

* Last but not least, it occured to me that the problematic (in the case
  of directory names with whitespace) find | xargs construct isn't
  necessary at all since it is just a performance optimization to avoid
  creating too many processes.  Since the number of .svn directories in
  those trees isn't that large, I think it's better to err on the side
  of caution and accept the possible performance penalty by using find
  -exec rm instead.

The patch below does just that.

Ok for mainline now?  Tested as above, and it fixes a regression in GCC
4.4/4.5.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University


2010-01-15  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	PR libgcj/38251
	* tools/Makefile.am (dist-hook): Prune .svn directories in asm and
	classes copies.
	* tools/Makefile.in: Regenerate.

	Revert:
	2008-11-05  Andrew Haley  <aph@redhat.com>

	* tools/Makefile.am (UPDATE_TOOLS_ZIP, CREATE_TOOLS_ZIP): Exclude
	.svn direcories.

diff -r da043a0a9cee libjava/classpath/tools/Makefile.am
--- a/libjava/classpath/tools/Makefile.am	Mon Jan 11 04:28:36 2010 +0000
+++ b/libjava/classpath/tools/Makefile.am	Wed Jan 20 17:49:17 2010 +0100
@@ -373,6 +373,9 @@
 ## BEGIN GCJ LOCAL
 	cp -pR $(srcdir)/asm .
 	cp -pR $(srcdir)/classes .
+	if [ -d asm/.svn ]; then \
+	  find asm classes -depth -type d -name .svn -exec rm -rf \{\} \;; \
+	fi
 ## END GCJ LOCAL
 if CREATE_GJDOC
 ## Copy over gjdoc resource files.
@@ -385,11 +388,11 @@
 endif
 
 if WITH_JAR
-CREATE_TOOLS_ZIP=$(JAR) cf ../$(TOOLS_ZIP) `find . -name .svn -prune -o -type f -print`
-UPDATE_TOOLS_ZIP=$(JAR) uf ../$(TOOLS_ZIP) `find . -name .svn -prune -o -type f -print`
+CREATE_TOOLS_ZIP=$(JAR) cf ../$(TOOLS_ZIP) .
+UPDATE_TOOLS_ZIP=$(JAR) uf ../$(TOOLS_ZIP) .
 else
-CREATE_TOOLS_ZIP=$(ZIP) -r ../$(TOOLS_ZIP) `find . -name .svn -prune -o -type f -print`
-UPDATE_TOOLS_ZIP=$(ZIP) -u -r ../$(TOOLS_ZIP) `find . -name .svn -prune -o -type f -print`
+CREATE_TOOLS_ZIP=$(ZIP) -r ../$(TOOLS_ZIP) .
+UPDATE_TOOLS_ZIP=$(ZIP) -u -r ../$(TOOLS_ZIP) .
 endif
 
 ## First add classpath tools stuff.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]